List of Archived Posts

2006 Newsgroup Postings (3/7 - 3/22)

About TLB in lower-level caches

About TLB in lower-level caches

When *not* to sign an e-mail message?

When *not* to sign an e-mail message?

When *not* to sign an e-mail message?

About TLB in lower-level caches

About TLB in lower-level caches

About TLB in lower-level caches

Beginner's Pubkey Crypto Question

terminals was: Caller ID "spoofing"

Caller ID "spoofing"

Caller ID "spoofing"

About TLB in lower-level caches

X.509 and ssh

X.509 and ssh

About TLB in lower-level caches

X.509 and ssh

X.509 and ssh

X.509 and ssh

About TLB in lower-level caches

About TLB in lower-level caches

Debit Cards HACKED now

Debit Cards HACKED now

Debit Cards HACKED now

Debit Cards HACKED now

About TLB in lower-level caches

Debit Cards HACKED now

X.509 and ssh

MCTS

X.509 and ssh

Debit Cards HACKED now

MCTS

transputers again was: The demise of Commodore

MCTS

CJ Date on Missing Information

The Pankian Metaphor

The Pankian Metaphor

The Pankian Metaphor

The Pankian Metaphor

The Pankian Metaphor

transputers again was: The demise of Commodore

CJ Date on Missing Information

SSL Certificate Signing

transputers again was: The demise of Commodore

Does the Data Protection Act of 2005 Make Sense

using 3390 mod-9s

using 3390 mod-9s

sci.crypt

About TLB in lower-level caches

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: About TLB in lower-level caches
Newsgroups: comp.arch
Date: Tue, 07 Mar 2006 15:23:23 -0700

"Dale Morris" writes:

The question of context switch is really independent of CMP or
resource sharing among logical processors.  In the old days, TLBs
were typically flushed on context switch, but today most designs
include information as part of the TLB mapping entry that makes it
unique within that OS environment. For example, the mapping might
include some sort of process ID tag.  An example would be Region IDs
in Itanium processors.  With this information, there's no need to
remove TLB entries on context switch.

virtual memory on 370/165 (early 70s) had a 7-entry sto-stack. tlb
entries had 3-bit sto-identifier ... which mapped to one of the
7-entries in the sto-stack (plus identifier for unused).

virtual address space had a segment table ... the address of which
(aka segment-table-origin) was loaded into segment table register
... and which the hardware used to uniquely identify a virtual address
space.

when segment register was changed, the hardware would check to see of
the address (sto) was already in the TLB sto-stack. if not, one of the
sto-stack entries was replaced and all the TLB-entries associated with
the sto-stack entry were automatically purged.

The lower-end 370s tended to flush their complete TLB on every segment
register switch.

the 165 implementation carried thru the 370/168 and into the 3033
(which started out being 168 wiring diagram mapped to faster chip
technology). one of the people that went on to later be an itanium
architect ... introduced "dual-address" space for the 3033
(instructions and support for directly accessing data in a different
virtual address space). For some operations, this would double the
number of active virtual address spaces and there were rumors at the
time of significant sto-stack (and therefor tlb-entry) thrashing as a
result.

misc. past posts mentioning sto-stack:
http://www.garlic.com/~lynn/94.html#46 Rethinking Virtual Memory
http://www.garlic.com/~lynn/99.html#204 Core (word usage) was anti-equipment etc
http://www.garlic.com/~lynn/2000g.html#10 360/370 instruction cycle time
http://www.garlic.com/~lynn/2001g.html#8 Test and Set (TS) vs Compare and Swap (CS)
http://www.garlic.com/~lynn/2002c.html#40 using >=4GB of memory on a 32-bit processor
http://www.garlic.com/~lynn/2002l.html#60 Handling variable page sizes?
http://www.garlic.com/~lynn/2003e.html#0 Resolved: There Are No Programs With >32 Bits of Text
http://www.garlic.com/~lynn/2003g.html#12 Page Table - per OS/Process
http://www.garlic.com/~lynn/2003g.html#13 Page Table - per OS/Process
http://www.garlic.com/~lynn/2003g.html#23 price ov IBM virtual address box??
http://www.garlic.com/~lynn/2003h.html#37 Does PowerPC 970 has Tagged TLBs (Address Space Identifiers)
http://www.garlic.com/~lynn/2003m.html#29 SR 15,15
http://www.garlic.com/~lynn/2005c.html#63 intel's Vanderpool and virtualization in general
http://www.garlic.com/~lynn/2005h.html#11 Exceptions at basic block boundaries
http://www.garlic.com/~lynn/2005h.html#18 Exceptions at basic block boundaries
http://www.garlic.com/~lynn/2005r.html#44 What ever happened to Tandem and NonStop OS ?

801 was originally designed to be a much more closed, proprietary,
dedicated environment. instead of segment table and segment table
register, it had inverted tables and segment-identifiers.
http://www.garlic.com/~lynn/subtopic.html#801

romp in the early 80s, implemented a 12-bit segment identifier.  romp
had 32bit virtual addressing ... the top four bits mapping to one of
sixteen segment registers. each segment register could have an
arbitrary 12bit segment identifier value. To do virtual->real mapping,
the hardware indexed a segment register (using the top four bits of
the virtual address), took the 12-bit segment identifier from the
segment register and then used to do a lookup in the TLB for the
appropriate virtual page entry (i.e. using 12-bit segment identifier
value, plus 16-bit virtual page number, within a segment). This was
sometimes referred to as 40-bit virtual address (combination of the
12-bit segment identifier value plus 28bit virtual address). It was
theoritically possible to have the same 12-bit segment identifier
appear in each of the 16 segment registers ... which would result in
16 different possible (32bit) virtual addresses all mapping to the
same TLB entry.

for rios/power, the segment identifier was doubled from 12bits to
24bits ... and you sometimes saw writeups describing the rios/power
implementation as being 52-bit virtual addressing.

for some drift, the original virtual machine virtualization support in
360 (and later 370) ... created "shadow" segment and page table for a
virtual machine (that translated from the virtual machine's "3rd"
level virtual memory to the hardware's "1st" level real memory) that
followed TLB (which happened to be called associative array on 360,
somewhat more expensive and fully associative) hardware rules. Every
time the virtual machine changed the virtual segment register, the
shadow table entries would be completely reset (i.e. the low-end 370
hardware model). In the mid-70s an performance enhancement was
implemented for virtual machine support that somewhat emulated the 168
sto-stack ... with multiple "shadow" tables possible for each virtual
machine.

misc. past posts mentioning virtual machine shadow table support:
http://www.garlic.com/~lynn/94.html#48 Rethinking Virtual Memory
http://www.garlic.com/~lynn/2002l.html#51 Handling variable page sizes?
http://www.garlic.com/~lynn/2003g.html#18 Multiple layers of virtual address translation
http://www.garlic.com/~lynn/2004c.html#35 Computer-oriented license plates
http://www.garlic.com/~lynn/2004o.html#18 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2005d.html#66 Virtual Machine Hardware
http://www.garlic.com/~lynn/2005d.html#70 Virtual Machine Hardware
http://www.garlic.com/~lynn/2005h.html#18 Exceptions at basic block boundaries
http://www.garlic.com/~lynn/2005k.html#42 wheeler scheduler and hpo
http://www.garlic.com/~lynn/2005n.html#47 Anyone know whether VM/370 EDGAR is still available anywhere?
http://www.garlic.com/~lynn/2005o.html#8 Non Power of 2 Cache Sizes
http://www.garlic.com/~lynn/2005p.html#45 HASP/ASP JES/JES2/JES3

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

About TLB in lower-level caches

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: About TLB in lower-level caches
Newsgroups: comp.arch
Date: Tue, 07 Mar 2006 18:28:39 -0700

Andy Glew writes:

Who was this?  (HM? DA?)

I know most of the itanium architects.

http://www.hpl.hp.com/news/2001/apr-jun/worley.html
http://www.hpl.hp.com/news/2001/apr-jun/itanium.html

and

had to go to the way-back machine for this one
http://web.archive.org/web/20000415125122/http://www.hpl.hp.com/features/bill_worley_interview.html

slightly related recent post
http://www.garlic.com/~lynn/2006.html#39 What happens if CR's are directly changed

for some real topic drift .. a dc3 flight from h*** in the late 60s to
visit him at cornell for a meeting about HASP
http://www.garlic.com/~lynn/2006b.html#27 IBM 610 workstation computer

other drift, after some number of people left for the labs in early
80s, i was getting frequent emails polling who else did i know that
might be joining them and/or whether i might also join them.

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

When *not* to sign an e-mail message?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: When *not* to sign an e-mail message?
Newsgroups: sci.crypt,comp.security.pgp.discuss
Date: Wed, 08 Mar 2006 10:06:29 -0700

Andrew Swallow writes:

In Britain the credit card companies no longer accept handwritten
signatures.  You have to type a 4 digit pin.

credit cards have been something you have authentication and the
hardwritten signature has been demonstration of intent.

pin-debit has had two-factor authentication, the card as something
you have and the pin as something you know ... from 3-factor
authentication model
http://www.garlic.com/~lynn/subintegrity.html#3factor

• something you have
• something you know
• something you are

with the standard pin-debit POS operation, you swipe your card
(something you have authentication) and enter your pin (something
you know authentication, pin/password shared-secrets can be
considered countermeasure to lost/stolen cards).

the POS then displays the value and asks you to press a yes/agree
button as a demonstration of intent (the equivalent of the "human
signature").

slight topic drift on the chip&pin subject:
http://www.garlic.com/~lynn/aadsm22.htm#20 FraudWatch - Chip&Pin, a new tenner

slightly more drift mentioning chip&pin:
http://www.garlic.com/~lynn/2006d.html#31 Caller ID "spoofing"

in the magstripe generation of cards ... reading the magstripe was
proof of something you have authentication. however, the magstripe
was "static data" and was subject to skimming/evesdropping
vulnerabilities and became fairly straight-forward to generate
counterfeit cards from the "static data".

the chip&pin is substituting public key and digital signature
operation in lieu of reading magstripe ... as proof of something you
have authentication (with the pin still something you know
authentication as countermeasure to lost/stolen card). however, the
authentication processes (including digital signature) are orthogonal
to establishing "intent" established by requiring somebody to press a
button (the "intent" equivalence that is also addressed by human
signature).

lengthy discussion, including use of public key and digital
signatures for establishing proof of something you have
authentication hardware token:
http://www.garlic.com/~lynn/2006d.html#41 Caller ID "spoofing"

past posts in this thread ... including discussion of POS pressing
button as evidence of intent (i.e. human signature) separate
from authentication processes:
http://www.garlic.com/~lynn/2006d.html#32 When *not* to sign an e-mail message?
http://www.garlic.com/~lynn/2006d.html#33 When *not* to sign an e-mail message?
http://www.garlic.com/~lynn/2006d.html#34 When *not* to sign an e-mail message?
http://www.garlic.com/~lynn/2006d.html#36 When *not* to sign an e-mail message?

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

When *not* to sign an e-mail message?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: When *not* to sign an e-mail message?
Newsgroups: sci.crypt,comp.security.pgp.discuss
Date: Wed, 08 Mar 2006 13:17:22 -0700

Anne & Lynn Wheeler writes:

slight topic drift on the chip&pin subject:
http://www.garlic.com/~lynn/aadsm22.htm#20 FraudWatch - Chip&Pin, a new tenner

ref:
http://www.garlic.com/~lynn/2006e.html#2 When *not* to sign an e-mail message?

in the above yes card scenarios, i've seen reference to a number of
different implementations.

the yes card scenarios supposedly are "static data" exploits
... i.e. the token authenticates itself by presenting a digital
certificate (i.e. static data) to the terminal. the terminal verifies
the digital signature on the certificate and accepts the card as
authenticated. this turned out to be vulnerable to the same skimming
technology that has been used for magstripes. there is some more
detailed information at the URL cited by the posting mentioned above.

the countermeasure becomes "dynamic data" ... the terminal
basically sends a form of challenge, which is digitally signed and
both the digital signature and the digital certificate is
returned. the terminal now verifies the digital signature on the
digital certificate and uses the public key in the digital certificate
to verify the digital signature on the challenge.

i've heard rumors of mitm-attacks tho ...  since the digital
signature on the challenge and the execution of the transaction are
separate, distinct operations. the countermeasure for
mitm-attack is to directly digitally sign the transaction
... as opposed to having separate operation for token digital
signature authentication and the execution of the transaction.

this then starts to look much more like the x9.59 model
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959

the original work on x9.59 for directly digitally signing the
transaction was going on in the same time-frame as the original work
on the definition for th chip&pin stuff ... where authentication
was going to be done separately from the transaction.

in any case, as in past posts on the subject, the verification of the
digital signature establishes the implication of something you
have authentication (aka the entity has access to and use of the
corresponding private key). then some certified process that binds a
private key to some chip ... then sort of establishes the equivalence
between something you have private key and something you
have chip.

however, digital signature isn't being used to imply intent as in
human signatures ... or in the human button pressing operation in
response to some message (as in POS terminal).

any change from doing a digital signature on a purely challenge
(possibly random data) authentication operation ... to applying a
digital signature to the transaction itself ... wouldn't be to create
any more of a (false) impression of human signature ... but to close
possible mitm-attacks that might be possible between doing an
independent authentication operation and then doing a separate
transaction (aka one of the original x9.59 countermeasure
scenarios).

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

When *not* to sign an e-mail message?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: When *not* to sign an e-mail message?
Newsgroups: sci.crypt,comp.security.pgp.discuss
Date: Wed, 08 Mar 2006 13:33:46 -0700

"nemo_outis" writes:

I would argue that a handwritten signature is not quite equivalent
to any of these.  However, it could be regarded as a derivative of
the something you are category with additional refinements.  [or
we could add a new category: "something you do"]

ref:
http://www.garlic.com/~lynn/2006e.html#2 When *not* to sign an e-mail message?

however, if you look at the contrast between signature-debit and
pin-debit .... signature-debit is effectively treated as a credit card
transaction from the standpoint of fraud ... while pin-debit is
considered to be two-factor authentication ... possibly lower fraud
(modulo the issue that it is possible for some skimming technology to
simultaneously capture both the magstripe and the pin ... defeating
some basic assumptions with multi-factor authentication that the
different factors are subject to independent threats/vulnerabilities).

POS terminals for pin-debit, w/o the signature and straight
two-factor authentication ... then goes to the interaction with
a message being displayed asking for the person to press a button to
establish "intent" (which is otherwise provided by a human signature).

within 3-factor authentication model ... human signature would
possible be something you are, since it is it would be taken as
distinctive representation of human physical characteristics.

however, there aren't a lot of current infrastructure deployments that
take human signatures as part of serious multi-factor authentication
infrastructure (not that you can't do it, it just doesn't seem to be
taken very seriously).

there was some work on elevating writting a signature to status of
acceptable something you are authentication .... it wasn't so much
the resulting signature ... but that the physical motions in executing
the signature have been demonstrated to be distinctive.

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

About TLB in lower-level caches

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: About TLB in lower-level caches
Newsgroups: comp.arch
Date: Wed, 08 Mar 2006 13:56:17 -0700

Anne & Lynn Wheeler writes:

virtual memory on 370/165 (early 70s) had a 7-entry sto-stack. tlb
entries had 3-bit sto-identifier ... which mapped to one of the
7-entries in the sto-stack (plus identifier for unused).

ref:
http://www.garlic.com/~lynn/2006e.html#0 About TLB in lower-level caches

for some additional drift ... there was actually quite a bit of
work put into the original 370 virtual memory architecture that
allowed for TLBs hardware implementations to be

1) simple, clear all entries, whenever switching address space

2) "sto-associative" ... this is from the above description, basically
TLB entries were associated with a "STO", segment table origin
... i.e. the real address of the start of segment table (which was
unique definition for a virtual address space).

3) "pto-associative" ... this is page-table origin associative.

370 had a virtual address space segment table with segment entries
that were pointers to the start of individual page tables (containing
page table entries mapping specific virtual page to real page
address). 370 architecture allowed for shared segments (i.e. the same
page table pointed to by different segment tables ... same page-table
appearing in different virtual address spaces).

I don't know of any general TLB hardware implementations that actually
did general pto-associative (i.e. multiple different address spaces
would have shared segment addresses mapping to the same TLB entries).

In effect, the 801 implementation (described in the original post) is
a flavor of pto-associative ... but for an inverted page table
architecture. since you don't have an explicit table, there is no
explicit table start address to uniquely identify each segment
... therefor the definition of arbitrary 12-bit segment identifier (in
romp) ... and later expanded to 24-bit segment identifier (for
rios/power).

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

About TLB in lower-level caches

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: About TLB in lower-level caches
Newsgroups: comp.arch
Date: Wed, 08 Mar 2006 19:38:47 -0700

"Eric P." writes:

What do you mean by "shadow table entries would be completely reset"?
Do you mean the TLB was flushed, or all the mapped physical pages
had to be released (like a working set flush), or something else?

shadow tables were page tables that emulated TLB semantics; aka
... shadow tables provided function equivalent to TLB but for the
operation of the virtual machine. processes that would result in
flushing entry in TLB needed to provide equivalent operation with
regard to the shadow tables .... in this case invalidating page table
entries ... which are the constructs used to emulate hardware TLB for
the virtual machine. Now such page table entries are being
invalidated real page tables (even if they are "shadow" table
constructs for the virtual machine), will, in turn require
that you turn around and flush entries in the real TLB.

the original 370 virtual memory architecture included hardware
instructions, IPTE (invalidate page table entry), ISTE (invalidate
segment table entry), and PTLB (purge table look-aside buffer).  IPTE
turns the invalid bit in the PTE entry and would flush any associated
TLB entry. ISTE turns the invalid bit in the STE entry and would flush
any associated TLB entries. PTLB flushes all TLB entries. IPTE and
ISTE instructions were dropped from original shipped products.

various web pages (from search engine) with more detailed discussion
about virtual machine implementation and shadow tables
http://www.cap-lore.com/Software/virtualVirtual.html
http://www.cs.duke.edu/~narten/110/nachos/main/node34.html
http://www.virtualization.info/archive/2005_01_01_archive.html
http://lists.xensource.com/archives/html/xen-devel/2004-08/msg00261.html
http://www.princeton.edu/~melinda/25paper.pdf
http://swpat.ffii.org/pikta/txt/ep/0171/475/
http://www.cs.princeton.edu/courses/archive/spring06/cos592/bib/future_trends-rosenblum.pdf
http://www.stanford.edu/class/cs240/readings/waldspurger.pdf
http://download.microsoft.com/download/9/8/f/98f3fe47-dfc3-4e74-92a3-088782200fe7/TWSE05008_WinHEC05.ppt
http://www.stanford.edu/~talg/papers/COMPUTER05/virtual-future-computer05.pdf
http://www.usenix.org/events/osdi02/tech/waldspurger/waldspurger_html/node3.html
http://www.vmware.com/pdf/esx2_performance_implications.pdf
http://www.cs.ubc.ca/~norm/cs538a/ibmrd2706L.pdf
http://www.cs.wisc.edu/~stjones/proj/vm_reading/ibmrd2706L.pdf
http://www.patentstorm.us/patents/4814975.html
http://www.uic.edu/depts/accc/inform/ibmglossary.html

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

About TLB in lower-level caches

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: About TLB in lower-level caches
Newsgroups: comp.arch
Date: Thu, 09 Mar 2006 11:49:35 -0700

Anne & Lynn Wheeler writes:

various web pages (from search engine) with more detailed discussion
about virtual machine implementation and shadow tables
http://www.cap-lore.com/Software/virtualVirtual.html
http://www.princeton.edu/~melinda/25paper.pdf

a little more shadow table lore. cp/67 originally only had virtual
machine support for vanilla 360 machines ... i.e. no virtual memory
support (no support for the virtual memory hardware shipped in
360/67s). cp/67 ran on 360/67 and made use of the virtual memory
hardware as part of providing (360) virtual machines ... but didn't
provide 360/67 virtual machine. as a result, cp/67 couldn't run "under"
cp/67.

one of the people at the grenoble science center got an assignment
at the cambridge science center
http://www.garlic.com/~lynn/subtopic.html#545tech

and while on the assignment, added 360/67 virtual machine support to
cp/67 (including the original shadow table support).

this was not too long before the joint cambridge/endicott ("cp67h" and
"cp67i") project started to provide 370 virtual machine support under
360/67. 370s were originally announced w/o virtual memory support, but
the architecture had been defined. the 370 virtual memory architecture
had some number of differences from that found in 360/67 including
some differences in the definition for the segment and page tables
(used by the hardware).

for the "cp67h" level changes to cp/67 ... there was mode-switch
defining whether 360/67 virtual memory was being emulated or 370
virtual memory was being emulated. the "shadow tables" were the same
format ... since they were being referenced by the real 360/67
hardware ... however, the segment and page tables that were in the
memory of the virtual machine ... which the cp/67 simulation worked
with ... were slightly different (but both formats need to be
translated to native hardware format for shadow tables).

minor trivia, some years later the person that had done the
original virtualizing 360/67 and shadow table support found
himself setting up EARN ... reference:
http://www.garlic.com/~lynn/2001h.html#65

misc. past posts mention "cp67h" and "cp67i" work (it was up and
running standard production ... a year before the first engineering
370 machine with virtual memory support was operational ... and well
before virtual memory for 370 was announced, other trivia, the
multi-level source update process was also developed as part of the
"cp67h" and "cp67i" effort)
http://www.garlic.com/~lynn/2002h.html#50 crossreferenced program code listings
http://www.garlic.com/~lynn/2002j.html#0 HONE was .. Hercules and System/390 - do we need it?
http://www.garlic.com/~lynn/2002j.html#70 hone acronym (cross post)
http://www.garlic.com/~lynn/2004b.html#31 determining memory size
http://www.garlic.com/~lynn/2004d.html#74 DASD Architecture of the future
http://www.garlic.com/~lynn/2004h.html#27 Vintage computers are better than modern crap !
http://www.garlic.com/~lynn/2004p.html#50 IBM 3614 and 3624 ATM's
http://www.garlic.com/~lynn/2005c.html#59 intel's Vanderpool and virtualization in general
http://www.garlic.com/~lynn/2005d.html#58 Virtual Machine Hardware
http://www.garlic.com/~lynn/2005d.html#66 Virtual Machine Hardware
http://www.garlic.com/~lynn/2005g.html#17 DOS/360: Forty years
http://www.garlic.com/~lynn/2005h.html#18 Exceptions at basic block boundaries
http://www.garlic.com/~lynn/2005i.html#39 Behavior in undefined areas?
http://www.garlic.com/~lynn/2005j.html#50 virtual 360/67 support in cp67
http://www.garlic.com/~lynn/2005p.html#27 What ever happened to Tandem and NonStop OS ?
http://www.garlic.com/~lynn/2005p.html#45 HASP/ASP JES/JES2/JES3
http://www.garlic.com/~lynn/2006.html#38 Is VIO mandatory?

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

Beginner's Pubkey Crypto Question

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Beginner's Pubkey Crypto Question
Newsgroups: sci.crypt
Date: Thu, 09 Mar 2006 16:45:31 -0700

Kristian Gjøsteen <kristiag+news@item.ntnu.no> writes:

Suppose we have a whistle-blower named Alice that sends you some
important documents encrypted with your public key and signed with
an anonymous key. She also includes the self-signed anonymous public
key. (She may want to send further communications to you, therefore
the signing.)

The evil corporation that was about to get exposed happily intercepts
the e-mail. They would really like to know the contents of the e-mail
in order to find the whistle-blower, but since it is encrypted with
your public key, they can't break it unless they can fool you into
decrypting it.

They remove the self-signature from the public key, inserts the
identity of Clara (not Eve, that would make you suspicious) in the
public key and registers it on every key server they can find. Then
they forward the original e-mail on to you, without the self-signed
anonymous public key.

there has been some number of glitches with some of the public key
digital signature scenarios over the years ... some of them
from concentrating way too hard on the original sender being
able to proove that they sent the message ... and ignoring some
of the other threats.

if the whistle-blower signed the unencrypted message, sent the
encrypted message, the digital signature and the public key
.. mitm-attack replacing the digital signature and public key
doesn't work because the mitm doesn't have access to the original
unsigned message ... this basically impacts the integrity of the
overall message. removing the signature and public key can be done
... but if the contents is kept confidential, then only the sender and
the recipient have knowledge of the contents ... which could be used
to substantiate future messages from the same entity.

another scenario is including the digital signature as part of
plain-test message before encryption ... so that it is encrypted along
with the rest of the message. in any case, responses can be posted to
public place which have been encrypted with the original public key
(only after there is high level of confidence that the public key
being used, has a trust chain that uniquely binds it to the original
message).

a similar, but different sequence cropped up over the definition and
use of the non-repudiation bit in digital certificates. basically you
have message (unencrypted or encrypted) with digital signature and
digital certificate attached. recent thread also mentioning
non-repudiation:
http://www.garlic.com/~lynn/2006d.html#32 When *not* to sign an e-mail message?
http://www.garlic.com/~lynn/2006d.html#36 When *not* to sign an e-mail message?

now lets say you have two different digital certificates for the same
public key ... one with the non-repudiation bit set and one w/o the
non-repudiation bit set. you intend to only authenticate some
data; package up the message, the digital signature, and the digital
certificate with the non-repudiation bit OFF and send
it. however, there is no proof which digital certificate you actually
attached to the package. the recipient wants to hold you to higher
liability ...  so they scour the internet for a copy of you digital
certificate with the non-repudiation bit set ON ... and
in some dispute, present the original message, the original digital
signature, and the substituted digital certificate (the one with the
non-repudiation bit set ON).  basic digital certificate
standards didn't appear to anticipate this sort of threat (in part
because there was enormous confusion about the non-repudiation
bit ... and whether it carried with it additional obligations).

this scenario sort of cropped up in the mid-90s with one of the
efforts to do a digitally signed payment transaction that included
attached digital certificate (as opposed to certificate-less
operation). One flyer to try and induce merchants to deploy
implementations ... was a suggestion that if consumers were to attach
digital certificates that included the non-repudiation bit
having been set ON, it would reverse the burden of proof in any
dispute (currently in any such dispute, the burden of proof is on the
merchant ... not the consumer).

A possible vulnerability for consumers that didn't want to attach
digital certificates with the non-repudiation bit set (and have
the burden of proof shifted to themselves in a dispute) was that the
protocol provided for no proof of the contents of attached digital
certificate (merchants could reduce their costs by attempting to
conjure up any valid digital certificate for the consumer's public
key, that included the non-repudiation bit). This approach was
eventually discredited along with most of the other hypothetical
suggestions for the non-repudiation bit in digital certificate
(aka it wasn't in the consumer's interest to claim
non-repudiation, however it was proposed that it would become
in the merchant's interest to show that they had a
non-repudiation certificate for each consumer).

Of course that wasn't the only problem facing the certificate-based
digitally signed payment transactions efforts. They had realized
by that time that the x.509 identity certificate standards stuff
represented significant privacy and liability issues ... so they
had already retrenched to relying-party-only certificates
http://www.garlic.com/~lynn/subpubkey.html#rpo

basically the financial institution takes in all the information and
records it in an account record (including any issued digital
certificate and associated public key). they then issue a
relying-party-only certicate which fundamentally contains only the
account number and the public key. whenever somebody does a payment
transaction ... they would include in the payment transaction all the
standard, necessary information in the transaction, digitally sign it
... and send off the transaction, the digital signature and the
relying-party-only ceritifcate attached.

the financial institution retrieves the account number from the
transaction, reads the account record, uses the public key from the
account record to verify the digital signature and discards the
attached digital certificate. It wasn't that the attached digital
certificate was just redundant and superfluous ... but it also
resulted in enormous payload bloat. The typical 8583 payment
transaction is on the order of 60-80 bytes. The digital certificate
attachment overhead (even for relying-party-only certificates)
was running 4k to 12k bytes (an enormous payload bloat of two
orders of magnitude, increasing transaction payload by a factor of 100
times for something that was useless, redundant and
superfluous).

the enormous digital certificate payload bloat was perceived as
a significant issue and the X9F financial standards group started a
project to define a compressed digital certificate standard for
financial transactions ... hoping to get digital certificate payload
down into the 300 byte range. One of the things that seemed to give them
the most benefit was to eliminate digital certificate fields that were
common across all the relying-party-only consumer certificates
issued by the same financial institution. I suggested to them that
they could even go further, not only could they eliminate all common
fields ... but using some basic principles of information theory, they
could eliminate all fields in the digital certificate that were
already in possession of the financial institution.

I was quickly able to show that it was possible to come up with a
digital certificate standard for zero-byte digital
certificates. This seemed to have significant benefit ... being able
to attach zero-byte digital certificates to every transaction,
which turned out to be useless, redundant and superfluous
anyway (since the financial institution was going to simply discard
them immediately, already having a copy of all the original
information stored in the account record).  It seemed to be much more
acceptable to demonstrate that useless, redundant and
superfluous zero-byte digital certificates were being
attached to every payment transaction (as opposed to saying that there
was no point to attach useless, redundant and superfluous
digital certificates at all).

misc. past posts about zero-byte digital certificate effort
http://www.garlic.com/~lynn/aadsmore.htm#client4 Client-side revocation checking capability
http://www.garlic.com/~lynn/2000f.html#15 Why trust root CAs ?
http://www.garlic.com/~lynn/2001c.html#58 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001g.html#65 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001i.html#16 Net banking, is it safe???
http://www.garlic.com/~lynn/2004d.html#7 Digital Signature Standards
http://www.garlic.com/~lynn/2004j.html#6 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004j.html#7 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004j.html#8 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004j.html#9 Smart card Authentification
http://www.garlic.com/~lynn/2005n.html#33 X509 digital certificate for offline solution
http://www.garlic.com/~lynn/2005o.html#31 Is symmetric key distribution equivalent to symmetric key generation?
http://www.garlic.com/~lynn/2006c.html#35 X.509 and ssh
http://www.garlic.com/~lynn/aadsm22.htm#4 GP4.3 - Growth and Fraud - Case #3 - Phishing

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

terminals was: Caller ID "spoofing"

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: terminals was: Caller ID "spoofing"
Newsgroups: alt.folklore.computers
Date: Fri, 10 Mar 2006 11:05:01 -0700

eugene@cse.ucsc.edu (Eugene Miya) writes:

My first were a combination of custom double keyboards hooked to
Tektronix refresh storage tubes (for high resolution graphics of
that era).  More buttons don't make the future.  I think I never
used a 3270 thru 3279 until much later.  I remember all kinds of bad
terminals LSI ADM-3s, etc.  If Dennis is lurking, one favorite were
HP 2640s with lots of memory (apparently export controlled, the only
way one would be a munition was if you dropped it from a plane), but
smart terminals never caught on despite the Blit and BBN.
Perkin-Elmers were PK as well for Ined.  Vt100s and 3270 were least
common denominators.

But in the end I really grew to appreciate termcap and termio, and
that's one part Unix history I want to make certain the historians
don't forget (over 300 entries the last time I bothered to look).

there was a Tektronix display add-on to 3277 terminal (called 3277ga,
i.e. 3277 graphics adaptor). Wire went into the side of
3277. low-level operating system programming looked like 3277 terminal
... however, application programming was able to generate terminal
data streams to drive the Tektronix display. somewhat could take
advantage of the 640kbyte/sec of the 3272/3277 channel/controller/coax
operation.

the monster displays were the GE/CALMAs ... found in some of vlsi chip
design operations. Used embedded HYPERChannel A400 adapters to provide
local area network for cluster of CALMAs. a couple past posts
mentioning CALMAs
http://www.garlic.com/~lynn/2002g.html#55 Multics hardware (was Re: "Soul of a New Machine" Computer?)
http://www.garlic.com/~lynn/2005r.html#24 What ever happened to Tandem and NonStop OS ?
http://www.garlic.com/~lynn/2005u.html#6 Fast action games on System/360+?

a few past posts mentioning 3277ga ... saw some use in some of the
internal vlsi chip shops as less expensive CALMAs
http://www.garlic.com/~lynn/2001f.html#49 any 70's era supercomputers that ran as slow as today's supercompu
http://www.garlic.com/~lynn/2001i.html#51 DARPA was: Short Watson Biography
http://www.garlic.com/~lynn/2002p.html#29 Vector display systems
http://www.garlic.com/~lynn/2004l.html#27 Shipwrecks
http://www.garlic.com/~lynn/2004l.html#32 Shipwrecks
http://www.garlic.com/~lynn/2004m.html#8 Whatever happened to IBM's VM PC software?

for some drift, lots of posts mentioning various HYPERChannel activities
http://www.garlic.com/~lynn/subnetwork.html#hsdt

for other drift ... collection of posts about taking interdata/3,
adding mainframe channel card and programming it to emulate mainframe
terminal controller. went thru several generations ... and later
Perkin-Elmer bought Interdata and they continued to be marketed under
the Perkin-Elmer brand
http://www.garlic.com/~lynn/subtopic.html#360pcm

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

Caller ID "spoofing"

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Caller ID "spoofing"
Newsgroups: alt.folklore.computers
Date: Sat, 11 Mar 2006 12:03:20 -0700

Anne & Lynn Wheeler writes:

So the approach by x9.59 was to eliminate the shared-secret status
of (x9.59) account numbers (i.e. akin to passwords, just knowing the
value enables impersonation and/or fraud) ... using strong
authentication as a substitute for strong privacy/confidentiality.

ref:
http://www.garlic.com/~lynn/2006d.html#26 Caller ID "spoofing"

note that pin is part of shared-secret infrastructure.

from 3-factor authentication,
http://www.garlic.com/~lynn/subintegrity.html#3factor

• something you have
• something you know
• something you are

where multi-factor is considered more secure if the different factors
are subject to different threats/vulnerabilities. pins (something you
know) were somewhat countermeasures to lost/stolen card (something
you have). however, reading magstripe on the card was
representation/proof of unique something you have. by the early 90s,
skimming technology was starting to appear that represented a common
threat to both pins (something you know) and cards (reading
magstripe to establish proof of something you have).

discussion of some vulnerability characteristics
http://www.garlic.com/~lynn/aadsm22.htm#20
http://www.garlic.com/~lynn/2006e.html#3

some URLs from earlier in the week about current attacks on
PINs
http://www.garlic.com/~lynn/aadsm22.htm#21

some URLs from today on PIN attacks:
PIN Scandal 'Worst Hack Ever'
http://yro.slashdot.org/yro/06/03/11/0543249.shtml
Worldwide Wave of Debit Card Fraud
http://www.pcworld.com/news/article/0,aid,125053,00.asp
Debit-card fraud continues
http://www.securityfocus.com/brief/160
New Theft Scam Targets Debit Cards
http://www.wsfa.com/Global/story.asp?S=4615928&nav=0RdDcDuj
Worldwide Wave of Debit Card Fraud
http://www.hackinthebox.org/modules.php?op=modload&name=News&file=article&sid=19588

basically all 3-factor types can use static data authentication
mechanisms ... i.e. information that can be recorded and later
reproduced for fraudulent purposes. this falls under the general
category of replay attacks. for multi-factor authentication to be
effective, different factors need to be subject to different
threat/vulnerabilities. in the case of the general category of replay
attacks ... at least one of the factors needs to be resistant to
recording and later replay/reproduction.

this analysis can also be approached from the standpoint of
availability and "no-single-point-of-failure" ... although in this
case it is more like "no-single-point-of-attack". misc. collected
posts on high-availability
http://www.garlic.com/~lynn/subtopic.html#hacmp

misc. other past posts mentioning static data and/or replay
attack threats/vulnerabilities.:
http://www.garlic.com/~lynn/aadsm12.htm#6 NEWS: 3D-Secure and Passport
http://www.garlic.com/~lynn/aadsm13.htm#27 How effective is open source crypto?
http://www.garlic.com/~lynn/aadsm13.htm#28 How effective is open source crypto? (addenda)
http://www.garlic.com/~lynn/aadsm13.htm#29 How effective is open source crypto? (bad form)
http://www.garlic.com/~lynn/aadsm13.htm#31 How effective is open source crypto? (bad form)
http://www.garlic.com/~lynn/aadsm14.htm#30 Maybe It's Snake Oil All the Way Down
http://www.garlic.com/~lynn/aadsm15.htm#25 WYTM?
http://www.garlic.com/~lynn/aadsm15.htm#36 VS: On-line signature standards
http://www.garlic.com/~lynn/aadsm16.htm#13 The PAIN mnemonic
http://www.garlic.com/~lynn/aadsm16.htm#22 Ousourced Trust (was Re: Difference between TCPA-Hardware and a smart card and something else before
http://www.garlic.com/~lynn/aadsm17.htm#2 Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)
http://www.garlic.com/~lynn/aadsm17.htm#13 A combined EMV and ID card
http://www.garlic.com/~lynn/aadsm17.htm#38 Study: ID theft usually an inside job
http://www.garlic.com/~lynn/aadsm17.htm#46 authentication and authorization (was: Question on the state of the security industry)
http://www.garlic.com/~lynn/aadsm17.htm#47 authentication and authorization ... addenda
http://www.garlic.com/~lynn/aadsm17.htm#50 authentication and authorization (was: Question on the state of the security industry)
http://www.garlic.com/~lynn/aadsm17.htm#51 authentication and authorization
http://www.garlic.com/~lynn/aadsm17.htm#55 Using crypto against Phishing, Spoofing and Spamming
http://www.garlic.com/~lynn/aadsm18.htm#6 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm19.htm#5 Do You Need a Digital ID?
http://www.garlic.com/~lynn/aadsm19.htm#7 JIE - Contracts in Cyberspace
http://www.garlic.com/~lynn/aadsm19.htm#18 Citibank discloses private information to improve security
http://www.garlic.com/~lynn/aadsm19.htm#27 Citibank discloses private information to improve security
http://www.garlic.com/~lynn/aadsm19.htm#41 massive data theft at MasterCard processor
http://www.garlic.com/~lynn/aadsm19.htm#43 massive data theft at MasterCard processor
http://www.garlic.com/~lynn/aadsm19.htm#45 payment system fraud, etc
http://www.garlic.com/~lynn/aadsm19.htm#46 the limits of crypto and authentication
http://www.garlic.com/~lynn/aadsm19.htm#47 the limits of crypto and authentication
http://www.garlic.com/~lynn/aadsm20.htm#1 Keeping an eye on ATM fraud
http://www.garlic.com/~lynn/aadsm20.htm#41 Another entry in the internet security hall of shame
http://www.garlic.com/~lynn/aadsm21.htm#16 PKI too confusing to prevent phishing, part 28
http://www.garlic.com/~lynn/aadsm22.htm#1 GP4.3 - Growth and Fraud - Case #3 - Phishing
http://www.garlic.com/~lynn/aadsm22.htm#2 GP4.3 - Growth and Fraud - Case #3 - Phishing
http://www.garlic.com/~lynn/aadsm22.htm#5 long-term GPG signing key
http://www.garlic.com/~lynn/aadsm22.htm#7 long-term GPG signing key
http://www.garlic.com/~lynn/2001b.html#43 John Mashey's greatest hits
http://www.garlic.com/~lynn/2001d.html#20 What is PKI?
http://www.garlic.com/~lynn/2002m.html#14 fingerprint authentication
http://www.garlic.com/~lynn/2003g.html#70 Simple resource protection with public keys
http://www.garlic.com/~lynn/2003j.html#25 Idea for secure login
http://www.garlic.com/~lynn/2003m.html#50 public key vs passwd authentication?
http://www.garlic.com/~lynn/2003o.html#3 Bank security question (newbie question)
http://www.garlic.com/~lynn/2003o.html#4 Bank security question (newbie question)
http://www.garlic.com/~lynn/2003p.html#6 Does OTP need authentication?
http://www.garlic.com/~lynn/2004b.html#43 The SOB that helped IT jobs move to India is dead!
http://www.garlic.com/~lynn/2004b.html#44 Foiling Replay Attacks
http://www.garlic.com/~lynn/2004b.html#45 Foiling Replay Attacks
http://www.garlic.com/~lynn/2004f.html#31 MITM attacks
http://www.garlic.com/~lynn/2004h.html#21 Basics of key authentication
http://www.garlic.com/~lynn/2004i.html#21 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004q.html#0 Single User: Password or Certificate
http://www.garlic.com/~lynn/2005e.html#31 Public/Private key pair protection on Windows
http://www.garlic.com/~lynn/2005f.html#62 single-signon with X.509 certificates
http://www.garlic.com/~lynn/2005g.html#33 Good passwords and security priorities
http://www.garlic.com/~lynn/2005g.html#46 Maximum RAM and ROM for smartcards
http://www.garlic.com/~lynn/2005g.html#48 "Best practices" or "Best implementations"?
http://www.garlic.com/~lynn/2005g.html#51 Security via hardware?
http://www.garlic.com/~lynn/2005i.html#1 Brit banks introduce delays on interbank xfers due to phishing boom
http://www.garlic.com/~lynn/2005j.html#64 More on garbage
http://www.garlic.com/~lynn/2005m.html#15 Course 2821; how this will help for CISSP exam ?
http://www.garlic.com/~lynn/2005m.html#37 public key authentication
http://www.garlic.com/~lynn/2005m.html#55 54 Processors?
http://www.garlic.com/~lynn/2005o.html#42 Catch22. If you cannot legally be forced to sign a document etc - Tax Declaration etc etc etc
http://www.garlic.com/~lynn/2005p.html#2 Innovative password security
http://www.garlic.com/~lynn/2005q.html#23 Logon with Digital Siganture (PKI/OCES - or what else they're called)
http://www.garlic.com/~lynn/2005s.html#52 TTP and KCM
http://www.garlic.com/~lynn/2005t.html#28 RSA SecurID product
http://www.garlic.com/~lynn/2005t.html#34 RSA SecurID product
http://www.garlic.com/~lynn/2005t.html#52 PGP Lame question
http://www.garlic.com/~lynn/2005u.html#1 PGP Lame question
http://www.garlic.com/~lynn/2005u.html#31 AMD to leave x86 behind?
http://www.garlic.com/~lynn/2005u.html#33 PGP Lame question
http://www.garlic.com/~lynn/2005v.html#2 ABN Tape - Found
http://www.garlic.com/~lynn/2005v.html#3 ABN Tape - Found
http://www.garlic.com/~lynn/2006d.html#31 Caller ID "spoofing"
http://www.garlic.com/~lynn/2006d.html#32 When *not* to sign an e-mail message?
http://www.garlic.com/~lynn/2006d.html#41 Caller ID "spoofing"
http://www.garlic.com/~lynn/2006e.html#2 When *not* to sign an e-mail message?

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

Caller ID "spoofing"

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Caller ID "spoofing"
Newsgroups: alt.folklore.computers
Date: Sat, 11 Mar 2006 13:46:48 -0700

Anne & Lynn Wheeler writes:

this analysis can also be approached from the standpoint of
availability and "no-single-point-of-failure" ... although in this
case it is more like "no-single-point-of-attack". misc. collected
posts on high-availability
http://www.garlic.com/~lynn/subtopic.html#hacmp

ref:
http://www.garlic.com/~lynn/2006e.html#10 Caller ID "spoofing"

sort of trivial example was when we started work on ha/cmp project,
there was a detailed vulnerability analysis (including tc/ip).  nearly
ten years later, the largest online service provider had been fighting
a tcp/ip vulnerability for a couple months and nobody (that they had
brought in so far) had been able to identify it. one day, one of the
people caught me after work and offered to buy me a hamburger while he
explained the problem. it turned out to be a relatively trivial (but
somewhat obscure) vulnerability that we had identified nearly ten
years earlier. a couple scribbled instructions that they applied later
that night was a quick&dirty fix for the problem.

a couple minor past refrences to the incident:
http://www.garlic.com/~lynn/aepay3.htm#aadsrel1 AADS related information
http://www.garlic.com/~lynn/2005c.html#51 [Lit.] Buffer overruns

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

About TLB in lower-level caches

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: About TLB in lower-level caches
Newsgroups: comp.arch
Date: Sun, 12 Mar 2006 15:03:24 -0700

"Eric P." writes:

So I suppose my question should have been, why the 3 levels and
full shadow rebuilds instead of 2 levels and guest access traps?
Performance, and/or compatibility with different 360/370
architectures are possibilities.

the virtual machine thinks it is running on the real hardware.

table 1:

the virtual machine operating system is running virtual address space
... which requires a mapping between what the operating system
(kernel) running in the virtual machine thinks are the virtual address
space mappings to what it thinks are its real addresses.

table 2:

the hypervisor running on the real hardware has a set of virtual
address tables for each virtual machine ... which gives the mapping
between what the virtual machine operating thinks are "real addresses"
(but in reallity are virtual addresses) and the "real", "real"
addresses of the real hardware.

when the hypervisor (providing virtual machines capability)
running on the real hardware ... dispatches a virtual machine
... the virtual machine may be expecting to run it real
address mode of the virtual machine (in which case, the
hypervisor loads the "table 2" into the appropriate hardware
registers.

table 3 (shadow table):

when the hypervisor (providing virtual machines capability) running on
the real hardware ... dispatches a virtual machine ... the virtual
machine may be expecting to run it virtual address mode of the virtual
machine. The virtual machine has specified "table 1" for
running. However, since "table 1" only provide address mapping from
the virtual address space mapping (maintained by the kernel running in
the virtual machine) to the virtual machine's "real addresses" ...
and since the virtual machine's "real addresses" aren't in fact
the real machine's real addresses ... using "table 1" would produce
invalid results.

as a result, the hypervisor running on the real hardware builds a
shadow of "table 1" ... which goes thru a double mapping. It takes an
entry from "table 1", and translates the virtual machine "real
address", using "table 2" to get the real, real address on the real
machine ... and places that value in the corresponding entry in the
"shadow table" (shadow of table 1).

the rules for maintaining the hardware TLB are followed for
maintaining the shadow of "table 1". This is because, in part because
the TLB architecture is defined as also being a shadow/copy of "table
1" (for the virtual machine) ... and can result in incorrect and/or
unpredictable results if the values in the TLB aren't kept in sync
with the values in entries from "table 1". The virtual machine
hypervisor takes advantage of the shadow/copy characteristics of the
real hardware TLB ... for maintaining the entries in the "shadow" of
"table 1". Note however, the "shadow table" (with translated
shadow/copy entries from "table 1") has to maintained consistent with
both the "table 1" entries as well as "table 2" entries.

the original shadow table implementation had only a single physical
set of storage for a shadow table for each virtual machine. This
corresponded with hardware tlb implementations that only remembered
entries for the current address space ... and didn't have capability
for remembering entries for multiple different address spaces. in this
implementation, every time there is a virtual address space change
... all the existing hardware tlb entries have to be
flushed. Simiarily, in the single shadaw table (per virtual machine)
implementation (where only entries for a single virtual address space
is remembered), everytime the virtual machine changes virtual address
space, all entries in the shadow table are flushed (faithfully
emulating what is done by hardware TLBs).

later shadow table implementations provided for having additional
storage allocated per virtual machine for remembering entries from
multiple different virtual address spaces (for a specific virtual
machine). this corresponds (and emulates) hardware tlbs that remember
entries from multiple differen virtual address spaces (multiple "table
1" per virtual machine). In this scenario ... there are a fixed,
maximum amount of fixed storage for shadow tables ... analogous to the
370/165 TLB description of being STO-associative and having a
seven-sto stack (can remember entries for up to seven different
virtual address spaces simultaneously). However, analogous to the
370/165 TLB description ... when a new address space is loaded that
doesn't correspond to one of the (saved) shadow tables ... and all the
existing physical shadow tables are already associated with a specific
"table 1" ... then one of the existing shadow tables has to have all
its entries flushed and that specific shadow table re-allocated to the
new virtual address space for the virtual machine (new "table 1" for
the virtual machine). Akin this emulates the rules for maintaining
hardware TLB entries.

Now, newer hardware with additional capability could provide virtual
machine hardware support for hardware TLB miss ... where the TLB miss
processing and TLB entry load ... recognizes that it is running in
virtual machine mode ... and that the hardware has to go thru a two
level lookup before obtaining the real, real address; aka this takes
the virtual real address entry from "table 1", does a 2nd lookup using
"table 2" ... in order to obtain, the real, real address (as opposed
to the virtual, real address) for loading into the real hardware TLB
entry.

The shadow table description is where the TLB hardware doesn't have
direct hardware support for doing the two-level table lookup (doing
the lookup in the virtual machine's Table1 ... and then doing a 2nd
lookup in the hypervisor's Table2 in order to obtain the real, real
hardware address) ... and the two-level lookup is done in software on
behalf of the hardware TLB ... and then when running that specific
virtual address space ... the hardware really runs using the "shadow
table" (when the hardware TLB implementation doesn't directly support
virtual machine operation mode and performing a two level lookup
automagically in hardware).

There is also a gotcha for any shadow-table bypass and virtual machine
hardware TLB two-level entry-miss & entry-load implementation and that
is recursive implementation. Part of early virtual machine work was
running a test virtual machine hypervisor under a production virtual
mahcine hypervisor ... where a guest virtual memory operating system
was being tested in the test virtual machine hypervisor. Now you have
three levels of tables (and, in theory, recursive might work to any
level). In the three level scenario:

virtual address space "LEVEL-1" running in virtual machine defined by
virtual address space "TABLE-1" of a operating system running in
a virtual machine

virtual address space "LEVEL-2" which the virtual machine operating
system thinks are real address, but is really defined by "TABLE-2" of
a virtual machine hypervisor "A" that thinks it is running on real
hardware

virtual address space "LEVEL-3" which the virtual machine hypervisor
"A" thinks are real address, but is really defined by "TABLE-3" of a
virtual machine hypervisor "B" that may or may not be running on real
hardware.

Now the real TLB hardware (that doesn't have any builtin two-level
lookup virtual machine capability) is expecting real virtual address
space tables to provide mapping from virtual address space to real,
real addresses (virtual page number to real, real page number).

The problem with "TABLE-1" defining virtual address space "LEVEL-1" is
not providing mapping between virtual addresses and the real, real
hardware page numbers ... "TABLE-1" entries provide mapping between
virtual addess space "LEVEL-1" and virtual address space "LEVEL-2"
... the mapping defined by "TABLE-2" (not the real, real hardware
addresses). Furthermore, the problem with "TABLE-2" is that doesn't
actually provide the mapping between virtual address space "LEVEL-2"
and the real, real hardware page numbers ... but it provides the
mapping between virtual address space "LEVEL-2" and the virtual
address space "LEVEL-3" defined by "TABLE-3". If this is truely
recursive ... it isn't until you get to "LEVEL-n" that you really have
a "TABLE-n" that is actually providing any mapping between a virtual
address space and the real, real page numbers.

So to generalize this, the virtual machine hypervisor at LEVEL-n,
builds shadow tables (that emulate the semantics of real hardware
TLBs) for virtual machine virtual address tables at LEVEL-(n-1).  The
virtual machine hypervisor shadow tables emulate the virtual address
space tables at LEVEL-(n-1) but using what it believes to be real
addresses at LEVEL-n. If the virtual machine hypervisor is really
running in a virtual machine recursive environment ...  there could be
several generations of shadow tables ... each providing for converting
the virtual, real page numbers at level (n-1) into page numbers of
level (n). It isn't until you get to the very bottom, real hardware
level do you finally encounter a shadow table that might get loaded
into the real, real hardware registers ... because it actually is the
only table that contains the real, real page numbers.

lots of past references to shadow tables
http://www.garlic.com/~lynn/94.html#48 Rethinking Virtual Memory
http://www.garlic.com/~lynn/2002l.html#51 Handling variable page sizes?
http://www.garlic.com/~lynn/2003g.html#18 Multiple layers of virtual address translation
http://www.garlic.com/~lynn/2004c.html#35 Computer-oriented license plates
http://www.garlic.com/~lynn/2004o.html#18 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2005d.html#66 Virtual Machine Hardware
http://www.garlic.com/~lynn/2005d.html#70 Virtual Machine Hardware
http://www.garlic.com/~lynn/2005h.html#18 Exceptions at basic block boundaries
http://www.garlic.com/~lynn/2005k.html#42 wheeler scheduler and hpo
http://www.garlic.com/~lynn/2005n.html#47 Anyone know whether VM/370 EDGAR is still available anywhere?
http://www.garlic.com/~lynn/2005o.html#8 Non Power of 2 Cache Sizes
http://www.garlic.com/~lynn/2005p.html#45 HASP/ASP JES/JES2/JES3
http://www.garlic.com/~lynn/2006e.html#0 About TLB in lower-level caches
http://www.garlic.com/~lynn/2006e.html#6 About TLB in lower-level caches
http://www.garlic.com/~lynn/2006e.html#7 About TLB in lower-level caches

various web pages (from search engine) with more detailed discussion
about virtual machine implementation and shadow tables
http://www.cap-lore.com/Software/virtualVirtual.html
http://www.cs.duke.edu/~narten/110/nachos/main/node34.html
http://www.virtualization.info/archive/2005_01_01_archive.html
http://lists.xensource.com/archives/html/xen-devel/2004-08/msg00261.html
http://www.princeton.edu/~melinda/25paper.pdf
http://swpat.ffii.org/pikta/txt/ep/0171/475/
http://www.cs.princeton.edu/courses/archive/spring06/cos592/bib/future_trends-rosenblum.pdf
http://www.stanford.edu/class/cs240/readings/waldspurger.pdf
http://download.microsoft.com/download/9/8/f/98f3fe47-dfc3-4e74-92a3-088782200fe7/TWSE05008_WinHEC05.ppt
http://www.stanford.edu/~talg/papers/COMPUTER05/virtual-future-computer05.pdf
http://www.usenix.org/events/osdi02/tech/waldspurger/waldspurger_html/node3.html
http://www.vmware.com/pdf/esx2_performance_implications.pdf
http://www.cs.ubc.ca/~norm/cs538a/ibmrd2706L.pdf
http://www.cs.wisc.edu/~stjones/proj/vm_reading/ibmrd2706L.pdf
http://www.patentstorm.us/patents/4814975.html
http://www.uic.edu/depts/accc/inform/ibmglossary.html

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

X.509 and ssh

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: X.509 and ssh
Newsgroups: comp.security.ssh
Date: Sun, 12 Mar 2006 20:25:19 -0700

"Richard E. Silverman" writes:

I was actually wondering why you constantly post rambling, multi-page
crypto-stream-of-consciousness, punctuated with pathetic ellipses where
you couldn't be bothered to actually complete a sentence.

But, this response is utterly priceless in its cluelessness, so thanks
anyway.

ref:
http://www.garlic.com/~lynn/2006c.html#37 X.509 and ssh

the referenced phd thesis analyzes my computer communications in
several hundred pages ... lot more detail than i could ever supply ...
if you are truely interested.

misc. related postings on computer mediated communication
http://www.garlic.com/~lynn/subnetwork.html#cmc

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

X.509 and ssh

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: X.509 and ssh
Newsgroups: comp.security.ssh
Date: Sun, 12 Mar 2006 20:50:46 -0700

"Nico Kadel-Garcia" writes:

Which doesn't explain why you ramble or fail to use periods correctly, and
the capital keys seem to be missing from your keyboard. It helps destroy any
content in what you're writing.

May I suggest that you that you examine and take to heart a copy of
Strunk's"Elements of Style"? It would help your work be more legible.

the thesis goes into all of those style issues in some detail ... in
addition to providing linquistic analysis of the styles ... if you are
really interested ... read the thesis.

i spent a couple years with senior publication editor in san jose
doing that sort of stuff for technical publications; turns out to be a
different mode/style of operation ... some of it was also during the
period that the material was being gathered for the phd research
... so some of those issues are also examined in some detail in the
thesis.

ref:
http://www.garlic.com/~lynn/2006c.html#37 X.509 and ssh
http://www.garlic.com/~lynn/2006e.html#13 X.509 and ssh

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

About TLB in lower-level caches

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: About TLB in lower-level caches
Newsgroups: comp.arch
Date: Mon, 13 Mar 2006 10:06:31 -0700

Jan Vorbrüggen <jvorbrueggen-not@mediasec.de> writes:

Doesn't the microcode and the VM implementation of some models have
an optimization for the one possible V=R virtual machine, often
running MVS?  That shortcuts most of the necessary translation
levels.

Amdahl introduced hardware hypervisor ... with V=R (and since there
is virtual=real, there is no two level lookup necessary)
http://www.garlic.com/~lynn/2006b.html#38 blast from the past ... macrocode

3090 eventually responded with PR/SM ... PR/SM eventually evolved into
the current LPARS (logical partitions; basically subset of virtual
machine support built into the fabric of the hardware, isn't V=R, but
supports small number of LPAR virtual machines) ... where many
mainframes are run with logical partition support as a matter of
standard production operation.

this abstract includes mention that z990 requires LPAR mode:

IBM Techdocs Technote: zSeries Performance: Determining the Logical CP
Requirements for a Partition
http://www-03.ibm.com/support/techdocs/atsmastr.nsf/032f6e163324983085256b79007f5aec/7eda0421b6d7af1586256db4001efbeb?OpenDocument

a few other references from around the web found with search engine

IBM: PR/SM for zSeries awarded certificate by German Fed Office for
Tec Security
http://www-03.ibm.com/servers/eserver/zseries/news/pressreleases/2003/z900securityaward_03-14-03.html
IBM Techdocs Flash: LPAR Management Time Performance Update
http://www-03.ibm.com/support/techdocs/atsmastr.nsf/fe582a1e48331b5585256de50062ae1c/bcbaeece31d0d9ff85256d8c000d4e4f?OpenDocument
IBM Redbooks | Modeling Host Environments using SNAP/SHOT
http://www.redbooks.ibm.com/abstracts/SG245314.html?Open

misc. past postings mentioning LPAR and/or PR/SM:
http://www.garlic.com/~lynn/2000.html#8 Computer of the century
http://www.garlic.com/~lynn/2000b.html#51 VM (not VMS or Virtual Machine, the IBM sort)
http://www.garlic.com/~lynn/2000b.html#61 VM (not VMS or Virtual Machine, the IBM sort)
http://www.garlic.com/~lynn/2000c.html#76 Is a VAX a mainframe?
http://www.garlic.com/~lynn/2000f.html#78 TSS ancient history, was X86 ultimate CISC? designs)
http://www.garlic.com/~lynn/2000g.html#3 virtualizable 360, was TSS ancient history
http://www.garlic.com/~lynn/2001f.html#17 Accounting systems ... still in use? (Do we still share?)
http://www.garlic.com/~lynn/2001h.html#33 D
http://www.garlic.com/~lynn/2002n.html#6 Tweaking old computers?
http://www.garlic.com/~lynn/2002o.html#15 Home mainframes
http://www.garlic.com/~lynn/2002o.html#18 Everything you wanted to know about z900 from IBM
http://www.garlic.com/~lynn/2002p.html#40 Linux paging
http://www.garlic.com/~lynn/2002p.html#44 Linux paging
http://www.garlic.com/~lynn/2002p.html#45 Linux paging
http://www.garlic.com/~lynn/2002p.html#46 Linux paging
http://www.garlic.com/~lynn/2002p.html#48 Linux paging
http://www.garlic.com/~lynn/2003.html#9 Mainframe System Programmer/Administrator market demand?
http://www.garlic.com/~lynn/2003.html#56 Wild hardware idea
http://www.garlic.com/~lynn/2003f.html#56 ECPS:VM DISPx instructions
http://www.garlic.com/~lynn/2003k.html#9 What is timesharing, anyway?
http://www.garlic.com/~lynn/2003n.html#13 CPUs with microcode  ?
http://www.garlic.com/~lynn/2003o.html#52 Virtual Machine Concept
http://www.garlic.com/~lynn/2004b.html#58 Oldest running code
http://www.garlic.com/~lynn/2004c.html#4 OS Partitioning and security
http://www.garlic.com/~lynn/2004c.html#5 PSW Sampling
http://www.garlic.com/~lynn/2004e.html#26 The attack of the killer mainframes
http://www.garlic.com/~lynn/2004f.html#47 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004j.html#45 A quote from Crypto-Gram
http://www.garlic.com/~lynn/2004k.html#37 Wars against bad things
http://www.garlic.com/~lynn/2004m.html#41 EAL5
http://www.garlic.com/~lynn/2004m.html#49 EAL5
http://www.garlic.com/~lynn/2004n.html#10 RISCs too close to hardware?
http://www.garlic.com/~lynn/2004o.html#13 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2004p.html#37 IBM 3614 and 3624 ATM's
http://www.garlic.com/~lynn/2004q.html#18 PR/SM Dynamic Time Slice calculation
http://www.garlic.com/~lynn/2004q.html#76 Athlon cache question
http://www.garlic.com/~lynn/2005.html#6 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005b.html#5 Relocating application architecture and compiler support
http://www.garlic.com/~lynn/2005b.html#26 CAS and LL/SC
http://www.garlic.com/~lynn/2005c.html#56 intel's Vanderpool and virtualization in general
http://www.garlic.com/~lynn/2005d.html#59 Misuse of word "microcode"
http://www.garlic.com/~lynn/2005d.html#70 Virtual Machine Hardware
http://www.garlic.com/~lynn/2005d.html#74 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005f.html#45 Moving assembler programs above the line
http://www.garlic.com/~lynn/2005h.html#13 Today's mainframe--anything to new?
http://www.garlic.com/~lynn/2005h.html#19 Blowing My Own Horn
http://www.garlic.com/~lynn/2005h.html#24 Description of a new old-fashioned programming language
http://www.garlic.com/~lynn/2005k.html#43 Determining processor status without IPIs
http://www.garlic.com/~lynn/2005m.html#16 CPU time and system load
http://www.garlic.com/~lynn/2005p.html#29 Documentation for the New Instructions for the z9 Processor
http://www.garlic.com/~lynn/2005u.html#40 POWER6 on zSeries?
http://www.garlic.com/~lynn/2005u.html#48 POWER6 on zSeries?
http://www.garlic.com/~lynn/2006b.html#38 blast from the past ... macrocode
http://www.garlic.com/~lynn/2006c.html#9 Mainframe Jobs Going Away

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

X.509 and ssh

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: X.509 and ssh
Newsgroups: comp.security.ssh
Date: Mon, 13 Mar 2006 10:20:17 -0700

"Nico Kadel-Garcia" writes:

Along with the repeated references to some PhD paper for which there
doesn't seem to be an actual link in the messages that repeatedly
reference it.  That's confusing at best.

actually there seems to be some additional semantic confusion.  there
was a question about "why" ... and i mentioned that there was a 9
month research project that studied how i communicated (person sat in
the back of my office for 9 months, took notes on all my voice
communication, also had copies of all my incoming and outgoing email
as well as logs of all instant messages). this research project also
resulted in a stanford phd thesis ... joint with language and comp. ai
departments ... as well as material for several subsequent books and
papers. in that literature, it goes into quite a bit of detail about
"why" ... quite a bit more than i could possibly explain.

there was no subsequent request for the actual references ... so it
appeared like the original question(s) were possible specious and
there was no serious interest in investigating why.

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

X.509 and ssh

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: X.509 and ssh
Newsgroups: comp.security.ssh
Date: Mon, 13 Mar 2006 10:42:12 -0700

Anne & Lynn Wheeler writes:

there was no subsequent request for the actual references ... so it
appeared like the original question(s) were possible specious and
there was no serious interest in investigating why.

the actual thesis isn't online ... possibly wait for the google book
scanning project and/or have access to the stanford library.

a couple more recent references to some of the work by the prime
researcher (found with search engine)
http://www.ncrel.literacy.smartlibrary.info/NewInterface/segment.cfm?segment=2369
http://llt.msu.edu/vol4num2/murray/

which includes the following items:

Denise E. Murray is Director of the National Centre for English
Language Teaching and Research, Macquarie University, Sydney,
Australia. She was founding Chair of the Department of Linguistics and
Language Development at San Jose State University. She has been
involved in ESL instruction and teacher education for more than 25
years. Her research interests include crosscultural literacy and the
interaction between language, society and technology. Her publications
include Knowledge machines: Language and information in a
technological society, and Diversity as resource: Redefining cultural
literacy.

Murray, D. E. (1988). The context of oral and written language: A
framework for mode and medium switching. Language in Society, 17,
351-373.

Murray, D. E. (1991). Conversation for action: The computer terminal
as medium of communication. Amsterdam: John Benjamins.

Murray, D. E. (1995). Knowledge machines: Language and information in
a technological society. London: Longman.

Murray, D. E. (1999). Access to information technology: Considerations
for language educators. Prospect, 14, 4-12.

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

X.509 and ssh

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: X.509 and ssh
Newsgroups: comp.security.ssh
Date: Mon, 13 Mar 2006 11:06:13 -0700

ref:
http://www.garlic.com/~lynn/2006e.html#13 X.509 and ssh
http://www.garlic.com/~lynn/2006e.html#14 X.509 and ssh
http://www.garlic.com/~lynn/2006e.html#16 X.509 and ssh
http://www.garlic.com/~lynn/2006e.html#17 X.509 and ssh
http://www.garlic.com/~lynn/2006e.html#18 X.509 and ssh

.... oh, and i did stumble across an old interim status report on the
research project ... partial extract ...

COMPOSITION AS CONVERSATION:
The Computer Terminal as Medium of Communication
Fifth Research Report
April 16th, 1985
Denise E. Murray
San Jose CA

DATA ANALYSIS

In this reporting period, I have concentrated on developing a
theoretical framework, driven by the data. This has included:

An Operational Definition of 'Conversation'. This is a paper to
be presented at the Stanford University School of Education Forum
for Research on Language Issues.

.....

Defining 'problem-solving' discourse.  This genre indicates structures
which achieve object transmission, information transmission,
direction, description, and information development.

...

Channel of communication is not arbitrary; channel may be chosen from
available options. This choice is motivated by field, tenor and mode
of discourse.

Characteristics of discourse depend on choices made along three
clines:

involvement/detachment
planning/spontaneity
collaboration/isolation

....

I have tallied the amount of computer correspondence and conversation
the subject has been engaged in over the past 6 months.

I have asked for statistical help. xxxxx has suggested SPSS available
on the IBM PC.

Presentations

I have written the first draft of the paper, COMPUTER CONVERSATION:
Adapting the Composing Process to Conversation, to be presented at the
International Conference on Computers and the Humanities, Brigham
Young University, June 26-28, 1985

I have written the first draft of the paper, When is a Conversation
not a Conversation? Operationalizing a Definition of the Object of
Discourse Study, to be presented at the Stanford University School of
Education Forum for Research on Language Issues, May 11, 1985.

... snip ...

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

About TLB in lower-level caches

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: About TLB in lower-level caches
Newsgroups: comp.arch
Date: Mon, 13 Mar 2006 15:14:57 -0700

"Eric P." writes:

Does VM limit the number of shadow PTEs that can be valid
at once similar to the real TLB, to say 128?

It could keep a circular FIFO buffer of the last 128 shadow entries
made valid, so that when a VM issues a PTLB there is just a
small number of shadow PTEs to invalidate.

This would make it behave just like a 128 entry software managed TLB.
To perform a PTLB it need only zap the 128 PTEs from the shadow table
listed in the circular buffer.

the shadow table is called a shadow table because it is an exact set
of hardware tables ... that correspond to the virtual tables ... but
instead of having translation from virtual to virtual real ...  takes
any miss for the virtual address, extracts the virtual/real address
from the virtual table ... and uses the virtual machine address tables
to translate from the virtual/real address to the real/real address.

it follows the semantics of TLB but uses real tables for the
implementation. in theory, if there is a valid entry in the virtual
table (located in the virtual tables in the virtual machine) ...  and
the corresponding virtual/real page for the virtual machine is in real
storage ... then the real/real page number populates the real page
table.

the architecture was careful about not specifying how TLBs were
implemented ... so that hardware engineers had great deal of latitude
in how they could do TLB implementation. As a result, it also provided
sufficient latitude to do shadow tables which were a full table set.

the original implementation didn't keep track of how many entries in
the shadow table had been made valid ... so that when a purge type
operation was required by the architecture of the hardware ... the
software implementation just did a complete clear of all possible
entries.

previous posts and more detailed references to the implementation:
http://www.garlic.com/~lynn/2006.html#6 UDP and IP Addresses
http://www.garlic.com/~lynn/2006e.html#0 About TLB in lower-level caches
http://www.garlic.com/~lynn/2006e.html#1 About TLB in lower-level caches
http://www.garlic.com/~lynn/2006e.html#5 About TLB in lower-level caches
http://www.garlic.com/~lynn/2006e.html#6 About TLB in lower-level caches
http://www.garlic.com/~lynn/2006e.html#7 About TLB in lower-level caches
http://www.garlic.com/~lynn/2006e.html#12 About TLB in lower-level caches
http://www.garlic.com/~lynn/2006e.html#15 About TLB in lower-level caches

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

About TLB in lower-level caches

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: About TLB in lower-level caches
Newsgroups: comp.arch
Date: Mon, 13 Mar 2006 15:40:23 -0700

"Eric P." writes:

Does VM limit the number of shadow PTEs that can be valid
at once similar to the real TLB, to say 128?

It could keep a circular FIFO buffer of the last 128 shadow entries
made valid, so that when a VM issues a PTLB there is just a
small number of shadow PTEs to invalidate.

This would make it behave just like a 128 entry software managed TLB.
To perform a PTLB it need only zap the 128 PTEs from the shadow table
listed in the circular buffer.

however, for some drift ... i had done an implementation in the early
70s that did something similar for a different reason.

there was an (internal corporate) activity trace tool called REDCAP
that used some virtual machine like technology to capture all I and D
(including differentiating loads/stores) and spit out a instruction
trace with storage references.

I got to modify that at the science center
http://www.garlic.com/~lynn/subtopic.html#545tech

in support of an internal tool ... that was eventually released in the
mid-70s as a product called vs/repack.

modification was made instead of spitting out an actual instruction
trace ... create a reference/use storage array representation for the
application ...  you could specify 16-byte, 32-byte, 64-byte, etc,
increments ... and would spit out the array at specified intervals
... say every 1000 or 5000 or 10000 instructions.

the three arrays were for instruction fetch, data fetch, and data
store ... with one bit indicating something had occured in that
storage line sometime during the specified instruction interval.

the application that eventually become vs/repack would take that
information ... along with map of the application and attempt to do
semi-automated program reorganization for optimal virtual memory
operation.

one of the things the science center used this analysis for was the
port of apl\360 from real-storage environment to cms\apl and a virtual
memory operation (including requiring redo of the whole apl storage
management and garbage collection). misc. postings mentioning
apl, cms\apl, etc
http://www.garlic.com/~lynn/subtopic.html#hone

it was also used by a number of internal product development
organizations ... not just for transition from real-storage paradigm
to virtual-address-space operation ... but also for generalized
execution characteristic operation analysis.

so it turned out that the full instruction emulation was somewhat
time-consuming and provided much greater detail than was needed for a
lot of application structure re-organization.

so i did a special modification of the kernel virtual address space
manager. a victim virtual address space could be selected and
specified as being monitored and not to ever have more than N PTEs
valid at any moment (akin to your description). Everytime the N+1 PTE
fault occured ... the list of current valid virtual page numbers would
be spit out ... and the existing N PTEs had their invalid flag turned
on (leaving the real page number in the PTE for translation purposes,
but indicating to the hardware that a page fault was to occur for that
virtual page). Then the TLB was reset ... and the process would
repeat. You sort of got a running indication of virtual pages that
were members of active working set for any period. The level of detail
was at a much grosser level than full instruction operation provided
by REDCAP ... but at much high performance ... and frequently good
enuf for the task at hand.

a few years later ... i did a similar kernel hack ... but instead of
tracking virtual page use ... tracked all disk file record use. this
was used against a number of different production environments as part
of designing disk and controller caches ... as well as some filesystem
design work. it was one of the first places where we started to see
detailed information about bursty use of file collections (i.e. the
same collection of files/records used once a day, or week, or month or
some other periodic basis).

misc. past posts referencing vs/repack
http://www.garlic.com/~lynn/94.html#7 IBM 7090 (360s, 370s, apl, etc)
http://www.garlic.com/~lynn/99.html#68 The Melissa Virus or War on Microsoft?
http://www.garlic.com/~lynn/2000g.html#30 Could CDR-coding be on the way back?
http://www.garlic.com/~lynn/2001b.html#83 Z/90, S/390, 370/ESA (slightly off topic)
http://www.garlic.com/~lynn/2001c.html#31 database (or b-tree) page sizes
http://www.garlic.com/~lynn/2001c.html#33 database (or b-tree) page sizes
http://www.garlic.com/~lynn/2001i.html#20 Very CISC Instuctions (Was: why the machine word size ...)
http://www.garlic.com/~lynn/2002c.html#28 OS Workloads : Interactive etc
http://www.garlic.com/~lynn/2002c.html#45 cp/67 addenda (cross-post warning)
http://www.garlic.com/~lynn/2002c.html#46 cp/67 addenda (cross-post warning)
http://www.garlic.com/~lynn/2002c.html#49 Swapper was Re: History of Login Names
http://www.garlic.com/~lynn/2002e.html#50 IBM going after Strobe?
http://www.garlic.com/~lynn/2002f.html#50 Blade architectures
http://www.garlic.com/~lynn/2003f.html#15 Alpha performance, why?
http://www.garlic.com/~lynn/2003f.html#21 "Super-Cheap" Supercomputing
http://www.garlic.com/~lynn/2003f.html#53 Alpha performance, why?
http://www.garlic.com/~lynn/2003g.html#15 Disk capacity and backup solutions
http://www.garlic.com/~lynn/2003h.html#8 IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
http://www.garlic.com/~lynn/2003j.html#32 Language semantics wrt exploits
http://www.garlic.com/~lynn/2004.html#14 Holee shit!  30 years ago!
http://www.garlic.com/~lynn/2004c.html#21 PSW Sampling
http://www.garlic.com/~lynn/2004m.html#22 Lock-free algorithms
http://www.garlic.com/~lynn/2004n.html#55 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2004o.html#7 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2004q.html#73 Athlon cache question
http://www.garlic.com/~lynn/2004q.html#76 Athlon cache question
http://www.garlic.com/~lynn/2005.html#4 Athlon cache question
http://www.garlic.com/~lynn/2005d.html#41 Thou shalt have no other gods before the ANSI C standard
http://www.garlic.com/~lynn/2005d.html#48 Secure design
http://www.garlic.com/~lynn/2005h.html#15 Exceptions at basic block boundaries
http://www.garlic.com/~lynn/2005j.html#62 More on garbage collection
http://www.garlic.com/~lynn/2005k.html#17 More on garbage collection
http://www.garlic.com/~lynn/2005m.html#28 IBM's mini computers--lack thereof
http://www.garlic.com/~lynn/2005n.html#18 Code density and performance?
http://www.garlic.com/~lynn/2005o.html#5 Code density and performance?
http://www.garlic.com/~lynn/2006b.html#15 {SPAM?} Re: Expanded Storage
http://www.garlic.com/~lynn/2006b.html#23 Seeking Info on XDS Sigma 7 APL

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

Debit Cards HACKED now

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Debit Cards HACKED now
Newsgroups: sci.crypt
Date: Mon, 13 Mar 2006 19:34:14 -0700

"Ed Weir \(ComCast\)" writes:

..."Unlike credit cards, debit cards offer an additional level of
security: the password-like Personal Identification Number, or PIN.
That's the irony, the PIN was supposed to make debit cards secure,"
Litan said. "Up until this breach, everyone thought ATMS and PINs
could never be compromised."

from 3-factor authentication model
http://www.garlic.com/~lynn/subintegrity.html#3factor

• something you have
• something you know
• something you are

... where magstripe cards have been a unique something you have
authentication. multi-factor authentication are considered more secure
when the different factors are subject to different/unique
threats/compromises. one of the ways of viewing pin/passwords
something you know (as part of multi-factor authentication ... in
conjunction with magstripe cards) are that they are a countermeasure
to lost/stolen cards (modulo the people that write their pins on their
cards).

however skimming techniques have been around for quite some time,
which could record both the magstripe information and entered pins at
the same time.  as a result, skimming created a common vulnerability
to both the magstripe information and the pin information (undermining
the benefits of having multi-factor authentication) ... aka the
recorded magstripe information could be used to create an acceptable
counterfeit card ... which then could be used in conjunction with
recorded pins. this can also be viewed as relatively straight-forward
analysis from the stand-point of replay attacks.

here is a reference looking into some aspects (modulo skimming
technologies)

Signature Debit Fraud Runs 15 Times Higher Than on PIN Debit Fraud
http://www.digitaltransactions.net/newsstory.cfm?newsid=738

from a a thread
http://www.garlic.com/~lynn/aadsm22.htm#22 FraudWatch - Chip&Pin, a new tenner

discussing various kinds of threats and vulnerabilities to
multi-factor authentication.

awareness of various pin-debit skimming technologies are so well-known
that you even see them used in some of the weekly (crime-oriented) TV
dramas (and in some syndicated daily reruns) ... where they've shown
in some detail, skimming implementations.

a few URLs found with simple search engine of atm, overlay, skimming
http://moneycentral.msn.com/content/Banking/P57803.asp
http://www.eubfn.com/arts/982_diebold.htm
http://www.csmonitor.com/2003/0721/p15s01-wmcn.html
http://www.atmmarketplace.com/news_story.htm?i=16235
http://www.ou.edu/oupd/idtheft3.htm
http://www.cknow.com/oldnewsletters/2002-01.html#atmskimming

the above search results even turns up some of my postings
http://www.garlic.com/~lynn/2005i.html#1

one of the countermeasures that have been used in conjunction with
online credit/debit transactions is to invalidate the account number
and issue a new card. this has tended to be more effective with
lost/stolen cards ... since the missing card tends to be
noticed. skimming (replay) attacks leave the original card in place
... and indications about fraudulent activity comes when somebody
checks their statement (or possibly if they get a rejected transaction
because all the money is gone).

a little more search engine use ... turns up reference to ABC 20/20
program from 11/8/1998 that looked at atm skimming
http://www.highbeam.com/doc/1P1:28890440/MONEY+MACHINE.html

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

Debit Cards HACKED now

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Debit Cards HACKED now
Newsgroups: sci.crypt
Date: Mon, 13 Mar 2006 21:02:35 -0700

late breaking news:
http://news.zdnet.com/2100-1009_22-6049290.html
http://news.com.com/Prosecutor+Debit+card+crime+ring+busted/2100-1029_3-6049290.html

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

Debit Cards HACKED now

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Debit Cards HACKED now
Newsgroups: sci.crypt
Date: Mon, 13 Mar 2006 21:09:38 -0700

and not quite so up to date
http://www.digitaltransactions.net/newsstory.cfm?newsid=880

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

Debit Cards HACKED now

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Debit Cards HACKED now
Newsgroups: sci.crypt
Date: Tue, 14 Mar 2006 08:03:29 -0700

Anne & Lynn Wheeler writes:

Signature Debit Fraud Runs 15 Times Higher Than on PIN Debit Fraud
http://www.digitaltransactions.net/newsstory.cfm?newsid=738

note, above article from last fall (2005) ....  slight clarification
... "signature debit" and "pin debit" doesn't refer to different
cards, the new generation of debit cards can be used in either
mode. as in previous post
http://www.garlic.com/~lynn/2006e.html#21 Debit Cards HACKED now

multi-factor authentication somewhat presumes that different factors
are vulnerable to different exploit/threats ... and that PIN has
somewhat been considered countermeasure to lost/stolen card (or
where the magstripe only has been skimmed).

the new generation of debit cards can be stolen (or counterfeited)
... and used for signature debit fraud w/o the pin (regardless of how
the card owner has used the card in the past).

skimming and harvesting
http://www.garlic.com/~lynn/subintegrity.html#harvest

technologies are capable of acquiring both the magstripe and PIN in
common operation ... underminning any presumed effectiveness of
multi-factor authentication (and presumptions of independent
vulnerabilities).

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

About TLB in lower-level caches

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: About TLB in lower-level caches
Newsgroups: comp.arch,alt.folklore.computers
Date: Tue, 14 Mar 2006 10:58:48 -0700

Anne & Lynn Wheeler writes:

however, for some drift ... i had done an implementation in
the early 70s that did something similar for a different reason.

ref:
http://www.garlic.com/~lynn/2006e.html#20 About TLB in lower-level caches

part of this was that the science center (4th flr, 545 tech
sq)
http://www.garlic.com/~lynn/subtopic.html#545tech

had done a lot of pioneering work in monitoring, profiling,
benchmarking, modeling, tuning, etc ... some minor drift
http://www.garlic.com/~lynn/subtopic.html#bench

that eventually evolved into such things as capacity planning.

that is besides having done the original virtual machine
implementation ... Melinda's historical paper
http://www.princeton.edu/~melinda/25paper.pdf

as well as having done the implementation used for the internal network
http://www.garlic.com/~lynn/subnetwork.html#internalnet

and, later, also for bitnet/earn
http://www.garlic.com/~lynn/subnetwork.html#bitnet

and lot of online/interactive stuff ... including invention of gml
(you might think stands for generalized markup language ... but
actually is initials of the inventor's last names) ... which later
morphed into html, xml, etc
http://www.garlic.com/~lynn/subtopic.html#sgml

the compare&swap instruction was also invented at the science center
("CAS" comes from the inventor's initials):
http://www.garlic.com/~lynn/subtopic.html#smp

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

Debit Cards HACKED now

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Debit Cards HACKED now
Newsgroups: sci.crypt
Date: Tue, 14 Mar 2006 14:08:34 -0700

shoppa writes:

Lots of outfits (including retail stores) use overhead video cameras
now, that probably do have a look-see at the PIN pad, and the video is
now stored digitally (don't want to put in a new tape every 6 hours?)
presumably on a PC at the store.

If also on that network you have the transaction-processing equipment,
this might be what they're talking about.

ref:
http://www.garlic.com/~lynn/2006e.html#21 Debit Cards HACKED now
http://www.garlic.com/~lynn/2006e.html#22 Debit Cards HACKED now
http://www.garlic.com/~lynn/2006e.html#23 Debit Cards HACKED now
http://www.garlic.com/~lynn/2006e.html#24 Debit Cards HACKED now

regardless of the initial installation of any possible anti-fraud
operation ... if there is any vector that can be used by crooks to get
what they want ... then it also has to be maintained securely.  This
is compromise of anti-fraud equipment as precursor to the actual fraud
.. common place is compromising the actual machines/infrastructure or
substituting with counterfeit machines

old security proportional to risk posting that looks at a slightly
different aspect of the situation. example is when the systemic risk is
possibly $50m or more, $1b? ...
http://www.digitaltransactions.net/newsstory.cfm?newsid=880

(i.e. value to the crooks), then, can a retailer afford the necessary
security? especially if the actual value to the retailer might possibly
be only a couple thousand?
http://www.garlic.com/~lynn/2001h.html#61

aside from the above, there is study about card fees already
accounting for over half of convenience store expenses (ahead of
labor) ... last paragraph in last article:
http://www.transactionworld.com/articles/2005/September/fraudUpdate1.asp

note that there are also a number of studies that repeately highlight
that the majority of fraud (even stuff that appears internet related)
involve insiders. old post about survey highlighting insiders
http://www.garlic.com/~lynn/aadsm18.htm#49 one more time now, Leading Cause of Data Security breaches Are Due to Insiders, Not Outsiders

and, of course, a few comments about such infrastructures then
requiring the whole planet to be buried miles deep in (data hiding)
crypto (but if the hidden/sensitive information may also be required in
numerous different business processes, then it is impossible to avoid
leakage ... especially when insiders might somehow be involved).
http://www.garlic.com/~lynn/aadsm15.htm#21 Simple SSL/TLS - Some Questions
http://www.garlic.com/~lynn/aadsm15.htm#27 SSL, client certs, and MITM (was WYTM?)
http://www.garlic.com/~lynn/aadsm19.htm#45 payment system fraud, etc
http://www.garlic.com/~lynn/2005u.html#3 PGP Lame question
http://www.garlic.com/~lynn/2006d.html#26 Caller ID "spoofing"

a 2002 article

Phony Interac terminals steal PINs, personal info
http://www.thevarsity.ca/media/paper285/news/2002/11/04/News/Debit.Card.Scam.Hits.York-314427.shtml?norewrite&sourcedomain=www.thevarsity.ca

2004 article (talks about skimming issues)

Canada's First Debit Fraud Estimate Pegs Losses at $44m
http://www.digitaltransactions.net/newsstory.cfm?newsid=366

2005 article ... comparing phishing to skimming for obtaining
information enabling account fraud

Turning Phishing into Cash: Criminal Convenience at the ATM?
http://www.securitymanagement.com/library/towergroup_phishing1105.pdf

the above article doesn't mention it, but a much more convenient
avenue for phishing account fraud possibly is something like online
banking ... as opposed to creating counterfeit cards for use at
physical machines.

early magstripe counterfeiting involved using an algorithm to generate
a valid appearing account number and then recording it on a
magstripe. magstripe cvv technology was introduced as
countermeasure to counterfeit magstripes generated from account
number algorithms.  this is also a countermeasure to magstripe
counterfeiting using account numbers obtained from phishing. however,
cvv technology wasn't a countermeasure to skimming technology
that recorded a complete, valid magstripe.

collection of past risk, fraud, exploits, vulnerability postings
http://www.garlic.com/~lynn/subintegrity.html#fraud

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

X.509 and ssh

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: X.509 and ssh
Newsgroups: comp.security.ssh
Date: Wed, 15 Mar 2006 11:22:10 -0700

"Nico Kadel-Garcia" writes:

Neither this nor your subsequent references actually names the paper
nor provides any ability to view the paper's material. I'm sure it's
very ego-gratifying to have a paper that mentions you, but since the
content of the paper is unavailable and you've in fact failed to
even describe what the paper said about your posting style, it's
pretty much an entirely useless reference. Isn't it?

In other words, there's no confusion: you've failed to actually
explain or justify your failure to use capitals, periods, or other
punctuation correctly and continue meandering about irrelevant
material.

I guess that the earlier statements weren't very clear that the phd
thesis and subsequent papers and books were based on analysis of
collected nine months of my communication. the communication examples
in the thesis and subsequent books and papers were anonymized so my
name never appeared (in addition a lot of technical content of what
was actually being discussed in the communication was frequently
obscured).

also from referenced status report mentioned here
http://www.garlic.com/~lynn/2006e.html#18 X.509 and ssh

the data collection effort and analysis was done under an IBM contract
managed out of the Los Angelos Scientific Center and resulted in a IBM
research report as well as Stanford phd thesis.  The dissertation
topic was Composition as Conversation: The Computer Terminal as
Medium of Communication (aka title of phd thesis). It was joint
between language department and computer ai department (I believe
terry winograd was thesis advisor on the computer side)

the earlier statments also reference that the collected material and
analysis was used for subsequent papers and books.

for some drift, various collected posts about cmc, some mentioning the
dissertation
http://www.garlic.com/~lynn/subnetwork.html#cmc

the only publication on the subject that i'm aware of from the period
(in the early 80s) that actually mentioned my name was a Datamation
article that had some references to my getting blamed for a lot of
online stuff that happened during the 70s and early 80s.

some of the activity referenced in the Datamation article is also
mentioned in various past postings about the internal network
... which was larger than than the arpanet/internet from the beginning
until approximately summer of 1985 ...  when the number of nodes in
the internet passed the number of nodes in the internal network.
http://www.garlic.com/~lynn/subnetwork.html#internalnet

note the internal network size doesn't include the academic bitnet (in
the US) and earn (in europe) which used the same technology as the
internal network (bitnet/earn was also larger than internet
in the early 80s)
http://www.garlic.com/~lynn/subnetwork.html#bitnet

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

MCTS

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: MCTS
Newsgroups: alt.folklore.computers
Date: Thu, 16 Mar 2006 10:51:48 -0700

Brian Inglis writes:

Is there available any old graphics software using 2250s?
AFAIR that was expensive proprietary or commercial CAD software.

Lincoln Labs. had written some fortran 2250 library stuff for cms
... and it was on cp67/cms that some people from cambridge came out
and installed in '68.

I adapted the lincoln labs fortran 2250 library stuff as device driver
for cms edit ... for a full screen editor (the univ. had 2250m1 ...
i.e. direct channel attach).

boeing hunstville had some sort of big 2250 operation ... they had a
two-processor 360/67 smp for driving 2250. they were running it with
specially modified os/mvt release 13 ... that didn't do any paging
... but used the 360/67 virtual memory hardware to get around os/mvt
storage fragmentation problems with the long running 2250
applications.

cambridge had a 2250m4 .... i.e. a 1130 as a controller/processor in
lieu of the 2250m1 channel controller box.  somebody had ported
spacewars to the machine ... and my kids would play ... the keyboard
layout was split in half with keys dedicated for movement, firing,
commands, etc ... for two-player operation.

later, some other vendor's display was remarketed as a 3250 (upgrade
for 2250).

later replacement for 3250s were 5080s.

less expensive was the 3277ga ... which was tektronics graphics
display hooked into side of 3277. recent reference
http://www.garlic.com/~lynn/2006e.html#9 terminals was: Caller ID "spoofing"

catia (still around) was widely used cad software for 2250.
http://www.3ds.com/index.php
http://www.3ds.com/fr/products-solutions/3d-for-all/virtools-dev-35/
http://www-306.ibm.com/software/applications/plm/catiav5/

somebody's cad "history" (from search engine)
http://joelorr.home.mindspring.com/id55.htm

another cad history (also mentions lincoln labs)
http://www.memagazine.org/backissues/april00/features/push/push.html

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

X.509 and ssh

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: X.509 and ssh
Newsgroups: comp.security.ssh
Date: Thu, 16 Mar 2006 13:03:04 -0700

Chuck writes:

You really should consider shorter responses. One or two sentences will
usually do.

past refs in thread:
http://www.garlic.com/~lynn/2006e.html#13 X.509 and ssh
http://www.garlic.com/~lynn/2006e.html#14 X.509 and ssh
http://www.garlic.com/~lynn/2006e.html#16 X.509 and ssh
http://www.garlic.com/~lynn/2006e.html#17 X.509 and ssh
http://www.garlic.com/~lynn/2006e.html#18 X.509 and ssh
http://www.garlic.com/~lynn/2006e.html#27 X.509 a