List of Archived Posts
2001 Newsgroup Postings (02/20 - 03/21)
- Z/90, S/390, 370/ESA (slightly off topic)
- Z/90, S/390, 370/ESA (slightly off topic)
- Z/90, S/390, 370/ESA (slightly off topic)
- Z/90, S/390, 370/ESA (slightly off topic)
- what makes a cpu fast
- what makes a cpu fast
- OS/360 (was LINUS for S/390)
- LINUS for S/390
- Server authentication
- Server authentication
- Memory management - Page replacement
- Memory management - Page replacement
- What does tempest stand for.
- LINUS for S/390
- Something wrong with "re-inventing the wheel".?
- OS/360 (was LINUS for S/390)
- database (or b-tree) page sizes
- database (or b-tree) page sizes
- On RC4 in C
- What is "IBM-MAIN"
- Something wrong with "re-inventing the wheel".?
- What is "IBM-MAIN"
- OS for IBM 370
- Use of ICM
- Use of ICM
- Use of ICM
- The Foolish Dozen or so in This News Group
- Massive windows waisting time (was Re: StarOffice for free)
- The Foolish Dozen or so in This News Group
- mini-DTR tapes? (was Re: The longest thread ever ...)
- PKI and Non-repudiation practicalities
- database (or b-tree) page sizes
- How Commercial-Off-The-Shelf Systems make society vulnerable
- database (or b-tree) page sizes
- PKI and Non-repudiation practicalities
- How Commercial-Off-The-Shelf Systems make society vulnerable
- How Commercial-Off-The-Shelf Systems make society vulnerable
- database (or b-tree) page sizes
- How Commercial-Off-The-Shelf Systems make society vulnerable
- PKI and Non-repudiation practicalities
- PKI and Non-repudiation practicalities
- PKI and Non-repudiation practicalities
- PKI and Non-repudiation practicalities
- PKI and Non-repudiation practicalities
- PKI and Non-repudiation practicalities
- PKI and Non-repudiation practicalities
- PKI and Non-repudiation practicalities
- PKI and Non-repudiation practicalities
- database (or b-tree) page sizes
- database (or b-tree) page sizes
- PKI and Non-repudiation practicalities
- PKI and Non-repudiation practicalities
- PKI and Non-repudiation practicalities
- Varian (was Re: UNIVAC - Help ??)
- PKI and Non-repudiation practicalities
- How Many Mainframes Are Out There
- PKI and Non-repudiation practicalities
- PKI and Non-repudiation practicalities
- PKI and Non-repudiation practicalities
- PKI and Non-repudiation practicalities
- PKI and Non-repudiation practicalities
- Risk management vs security policy
- SSL weaknesses
- SSL weaknesses
- confused about active scripting and security
- Key Recovery System/Product
- KI-10 vs. IBM at Rutgers
- What ever happened to WAIS?
- IBM Glossary
- Wheeler and Wheeler
- Wheeler and Wheeler
- Wheeler and Wheeler
- PKI and Non-repudiation practicalities
- PKI and Non-repudiation practicalities
- database (or b-tree) page sizes
- CNN reports...
- Unix hard links
- CNN reports...
- Unix hard links
- Q: ANSI X9.68 certificate format standard
- Unix hard links
- Unix hard links
- ARP timeout?
- CNN reports...
- database (or b-tree) page sizes
- Unix hard links
- A future supercomputer
- "Bootstrap"
- Unix hard links
- database (or b-tree) page sizes
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Z/90, S/390, 370/ESA (slightly off topic)
Newsgroups: comp.lang.asm370
Date: Tue, 20 Feb 2001 23:26:48 GMT
richgr@panix.com (Rich Greenberg) writes:
Complete with occasional CP abends on the service consoles.
but dumprx was available on those machines ....
random refs:
http://www.garlic.com/~lynn/94.html#11
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Z/90, S/390, 370/ESA (slightly off topic)
Newsgroups: comp.lang.asm370
Date: Wed, 21 Feb 2001 13:15:14 GMT
Randy Hudson writes:
In Tanenbaum's _Structured Computer Organization_, I believe he cites
a 30-1 speedup for microcoded FORTRAN programs, over simply compiling
them, on a 370/158. But that probably refers to writing the
application program directly in microcode, rather than just
microcode-assisted FORTRAN.
--
Randy Hudson <ime@netcom.com>
the <158 machines were vertical microcoded machines ... i.e. the
360/370 sequences of instructions tended to have same characteristics
as the microcode. 158/168 were horizontal microcode machines ... the
programming nature was quite different.
also in 158 time-frame ... there were people that were taking some
extremely performance sensitive fortran programs running on 195s and
hand-coding selected performance sensitive sequences directly in 370
assembler and getting 10:1 speedups (or better i.e. comparing hand
coded machine language vis-a-vis fortran compiler generated machine
language). I believe that a lot of the work on assemblers better than
assembler F ... were people involved in high performance computing
optimization (a lot of the stuff that went into assembler H and some
of the other varieties).
there was some work that on 158/168 ... that if the machine didn't
have to check if i-stream code modifications that you might get a 2:1
speedup ... the i-stream fetched a double word of instructions and
started some overlap of decode and execution. however, 360/370 allowed
that the previous instruction could do a store and totally overlay the
following instruction ... which introduced some stall in the amount of
overlap that could be done (which goes away with direct microcode
implementation).
in the vertical microcoded machines things were frequently expressed
in the number of native engine instructions needed to implement
360/370 instruction set. because of the totally different nature of
horizontal microcode, things were typically expressed in terms of
machine cycles. I remember that one of the differences going from 165
to 168 was the reduction of avg. machine cycles per instruction from
2.1 to 1.6 (while the cycle time didn't change). The 3033 further
reduced that to about 1.0 (and simple straight-forward translation of
370 instructions sequences to microcode showed little or no
performance improvement).
sometimes it was possible to get 30:1 speedup with hand-generated
machine code compared to fortran generated machine code.
in any case, on 158 going from fortran to microcode there were larger
number of factors compared to simulating one machine language
instruction set in the same or similar machine language instruction
set.
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Z/90, S/390, 370/ESA (slightly off topic)
Newsgroups: comp.lang.asm370
Date: Wed, 21 Feb 2001 14:15:42 GMT
Randy Hudson writes:
Anne & Lynn Wheeler wrote:
>370/145/148 were one of the most frequently microcoded engines. the
>:"APL" microcode ran APL at 10 faster than native(?) 370 (APL on 145
>w/microcode assist ran about same thruput as APL on 168 w/o microcode
>assist).
In Tanenbaum's _Structured Computer Organization_, I believe he cites
a 30-1 speedup for microcoded FORTRAN programs, over simply compiling
them, on a 370/158. But that probably refers to writing the
application program directly in microcode, rather than just
microcode-assisted FORTRAN.
just to further confuse the issues ...the APL comparison wasn't
comparing APL compiler generated 360 machine language vis-a-vis a
hand-generate horizontal microcode ... APL was an interpreter
... effectively when talking about running an APL program ... it is
the execution of the APL interpreter against different kinds of
data. It was pieces of the APL interpreter that were dropped into the
145 microcode. Going to Fortran, it is more compareable to talk about
dropping pieces of the Fortran compiler into microcode and comparing
the different of the straight machine language compiler vis-a-vis the
microcode version.
Going from running a non-microcded version of the APL interpreter
against a particular APL program compared to directly implementing the
function of an APL program in microcode might show a 100:1 improvement
(or better).
In the early 70s, the internal HONE system (all field, branch and many
hdqtrs function) was totally a CMS/APL and then APL/CMS environment
with some amount of shared segments for both CMS and APL. The CP/67
version of HONE and the early VM/370s version didn't provide for any
graceful way of transitioning between the APL environment and a
non-APL environment (because of the way that shared segments were
implemented).
Some amount of the HONE delivered applications were APL simulation
models. To a large extent these served the business functions that
today are implemented in spreadsheets allowing business people to pose
what-if questions. Other APL applications where configurators
... which walked the salesman thru a sequence of Q&A for specifying a
machine (starting with the 370/125 it was no longer possible for a
salesman to order/specify a machine w/o the help of a HONE
configurator; again a type of function today that would be frequently
implemented in a spreadsheet).
HONE also delivered some number of very sophisticated performance
modeling tools, including allowing a SE to take detailed customer
performance data and feed it to the modeling tools and be able to
provide reasonable guestimates for the customer as to the effect of
faster processor and/or more memory would have on the customer's
workload thruput.
For some of these more sophisticated application models, it was
possible to recode the APL implementation in Fortran, compile the
Fortran and show that the compiled Fortran executed possibly 50 times
faster than the interpreted APL version.
In any case, I had done an enhancement to CP/67 for generalized shared
memory support late in the CP/67 cycle (release 1 of VM/370 was
already available to customers). For HONE, I converted that to VM/370
r2plc15 base. The use of this at HONE was so that they could
transparently slip back&forth between the generalized end-user
environment (implemented in APL/CMS) and the growing number of
performance sensitive applications that had been recoded in Fortran.
A small subset of this was incorporated into the product in release 3
of VM/370 called discontiguous shared segments. However, it didn't
include the memory mapped file system and/or the ability to memory map
arbritrary CMS executables/modules (including the abilility for CMS
modules to be generated with portions of the memory-mapped region
specified as shared memory ... and for CMS kernel to automatically
invoke the shared memory specification as part of invoking a CMS
executable).
Totally, unreleated, I recently ran into somebody who had obtained the
rights to a descendent of the HONE performance modeling tool and had
taken an APL->C translator to it and was doing a lot of performance
analysis work (for instance, it had some interesting things to say
about the performance costs of turning on parallel sysplex).
random refs:
http://www.garlic.com/~lynn/95.html#3
http://www.garlic.com/~lynn/97.html#4
http://www.garlic.com/~lynn/98.html#23
http://www.garlic.com/~lynn/99.html#38
http://www.garlic.com/~lynn/99.html#149
http://www.garlic.com/~lynn/99.html#150
http://www.garlic.com/~lynn/2000e.html#0
http://www.garlic.com/~lynn/2000e.html#22
http://www.garlic.com/~lynn/2000f.html#30
http://www.garlic.com/~lynn/2000f.html#62
http://www.garlic.com/~lynn/2000g.html#27
http://www.garlic.com/~lynn/2001.html#0
http://www.garlic.com/~lynn/2001.html#26
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Z/90, S/390, 370/ESA (slightly off topic)
Newsgroups: comp.lang.asm370
Date: Wed, 21 Feb 2001 14:52:36 GMT
Randy Hudson writes:
In Tanenbaum's _Structured Computer Organization_, I believe he cites
a 30-1 speedup for microcoded FORTRAN programs, over simply compiling
them, on a 370/158. But that probably refers to writing the
application program directly in microcode, rather than just
microcode-assisted FORTRAN.
random other 158 trivia .... the 158 was time-shared between the 370
function and the channel function ... going to 3031 (where there were
two 158 engines, one with 370 feature and no channel function, and a
channel director 158 engine with the channel function and no 370
support) also showed improved 370 instruction thruput:
refs:
http://www.garlic.com/~lynn/2000d.html#0
a directly microcoded function on the 158 would have some more
latitude to play games vis-a-vis cycle stealing of the channel
function.
from much earlier in this same thread:
http://www.garlic.com/~lynn/2001b.html#69
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: what makes a cpu fast
Newsgroups: comp.arch
Date: Wed, 21 Feb 2001 15:19:20 GMT
cecchi@signa.rchland.ibm.com (Del Cecchi) writes:
And since each plant has a local copy of the mask, before the wafers
are exposed the operator has to check if it is the current copy or if
there is an updated copy available. This is done at IBM by an internal
network called VNET.
and to be totally off topic ... VNET effectively included a gateway
function as part of each node, essentially from the beginning ... and
contributed to one of the reasons that the internal network was larger
than the whole arpa/internet from just about the beginning until
sometime around 1985 (change in part because of the proliferation of
individual workstations & PCs as internet network nodes).
the internet didn't really get gateway function until the great
cut-over on 1/1/83 from NCP/IMPs to IP (at which time arpa/internet
was approx. 250 nodes and the internal network was nearly 1000 nodes).
random refs:
http://www.garlic.com/~lynn/2001b.html#81
http://www.garlic.com/~lynn/2000e.html#18
http://www.garlic.com/~lynn/internet.htm
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: what makes a cpu fast
Newsgroups: comp.arch
Date: Wed, 21 Feb 2001 16:02:54 GMT
cecchi@signa.rchland.ibm.com (Del Cecchi) writes:
And since each plant has a local copy of the mask, before the wafers
are exposed the operator has to check if it is the current copy or if
there is an updated copy available. This is done at IBM by an internal
network called VNET.
& i guess to totally round it off ... there was an internal
application called TOOLSRUN (was also the precursor of listserv)
... but as deployed it could be configured with flavors of mailing
list exploder (akin to current listserv/majordomo with all the
maint. & administrative function/feature), one-way broadcast (akin to
existing usenet), and master/slave distributed database (master &
slaves interact directly with push, pull & consistency protocols,
updates were done by the master and distributed out to all the
slaves).
local user could interact in such a way that a consistency check was
made with regard to a locally shadowed copy.
TOOLSRUN ran on top of VNET ... similar to the way that much of usenet
is currently configured running on top of tcp/ip (as opposed to the
uucp usenet flavors).
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: OS/360 (was LINUS for S/390)
Newsgroups: bit.listserv.ibm-main
Date: Wed, 21 Feb 2001 16:18:26 GMT
listmanager@SNIPIX.FREESERVE.CO.UK (Roger Bowler) writes:
IMO this is not correct. S/360 did not have EC mode, this was
introduced in S/370. OS/360 runs in BC mode only, even on a S/370.
Later releases of OS/360 make limited use of control registers (for
example CR2 is needed to support more than 6 channels), but it
never runs in EC mode.
slight caveat
360/67 had EC mode, control registers, virtual memory, channel
director supporting more than 7 channels (i.e. in 360/67 duplex
channel directory provide capability for all processors to access all
channels), 24&32bit addressing. In fact, the channel director
capability disappeared in 370 and don't really show up again until
308x.
370 prior to virtual memory & ec-mode announce had a couple bits
defined in cr0 not associated with ec-mode, multiprocessing, or
virtual memory. I don't remember how many of the other non-ec &/or
possibly later announced CR functions were in available at initial 370
first customer ship.
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: LINUS for S/390
Newsgroups: bit.listserv.ibm-main
Date: Wed, 21 Feb 2001 20:34:34 GMT
astaller@TOTALSYSTEM.COM (Al Staller) writes:
Are you sure about the "that the original S/370 announcement didn't
include DAT, " ?
I was in a presentation for the 370 (155?) and I am almost positive
they talked about the DAT box. But you may be correct as when I
walked out of there, I distinctly remember thinking to myself its
going to run like a dog as the power to do address translations will
take away from from the processor. We are talking at least 30-32
years ago and my memory is going the way of non-ECC .
Ed
very definitly the original 370 announcement didn't include DAT. There
was in fact, some big pentagon-paper-like flap with some DAT
information leaking to the press ... which (in part) resulted in
internal copying machines being retrofitted with serial numbers on the
glass ... so that all copies made with that machine would include the
copy machine identification. Before DAT announcement, there were also
customers asking what was the meaning of the "XLAT" light that was on
the front panel of 145s.
also, there was a problem retrofitting the full DAT function to the
165 (as defined in the base 370 document for all machines). 165
engineers claimed that the engineering to retrofit some of the DAT
features to the 165 would delay the availability by six months and
significantly increase the complexity of the hardware field upgrade
... as a result they got dropped from the 370 announcement from all
models (and in the case of 145 which already had done the full
architecture implementation, the eventual implementation shipped to
customers had to be stripped back to only those things that the 165
would be support).
One of the features that got dropped were all the selective invalidate
instructions, IPTE, ISTE, and ISTO .... leaving just PTLB.
random refs:
http://www.garlic.com/~lynn/2000e.html#15
http://www.garlic.com/~lynn/2000f.html#55
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Server authentication
Newsgroups: comp.security.misc
Date: Wed, 21 Feb 2001 20:18:14 GMT
Patrick.Knight@currentechnologies.com (Patrick Knight) writes:
That's what I thought. How can authentication be done without a third
party (i.e. certificates, CA)? In other words, how can a client know a
server is a server and not someone spoofing the network? Or for that
matter, without certificates how can a client authenticate itself to a
server without certificates?
actually, certificates are a second order binding between a server and
a client. certificates typically provide a binding between a public
key and some external identification for use in offline environments.
two parties with no prior relationship may frequently not have a
context for the externail identification and so the certificate means
nothing.
in general, until i set-up an account with some random ISP for my name
.... the ISP is unlikely to let me connect and provide me with service
just because I have sent them a certificate. they will typically want
some context where the account incurs charges and process for them to
be payed for the incurred charges.
looking at the internet, possibly 99.9999999999% of instances of
client/server authentication events that goes on in the internet world
occurs today using some sort of radius; i.e. consumer calls their ISP
(server), connects, performs some hand-shaking authentication
procedure and is granted access to the internet.
This occurs tens of millions and possibly hundreds of miliions of
times each day.
This process involving 99.999999999% of the existing internet
client/server authentication events typically involves some form of
userid/account and password.
The radius infastructure involving 99.99999999% of the existing
internet client/server authentication events could relatively
trivially support public/private key and still not require a
certificate.
A typical certificate-based authentication process, involves some sort
of secure message, which has a digital signature appended, and then a
certificate appended to the combined secure message and digital
signature. The recipient then uses the public key bound in the
certificate to verify the digital signature. This implies that the
message was presumably transmitted by the owner of the certificate and
that the message hasn't been modified in transit. The recipient then
typically uses a combination of the contents of the secure message,
the certificate and local administrative context to perform some
action in conjunction with the authentication (typically
authentication isn't being performed in the total absence of any
reason .... i.e. typical business process scenerio is using
authentication in conjunction with some sort of authorization,
typically requiring a business context).
Now, a trivial way of adding an upgrade option for 99.99999999% of the
existing internet client/server authentication events is to record the
client's public key in place of a password or other authentication
mechanism.
In this scenerio, the client forms a secure message, digital signes
it, and transmits the secure message plus digital signature (w/o
needing an associated certificate, note this can represent a real
savings on traffic bloat where the size of a digital certificate is an
order of magnitude bigger or more than the combined secure message
plus digital signature). The server recipient obtains the transaction
context pointer from the secure message, retrieves the context which
also contains the public key; uses the public key to verify the
digital signature ... and if it verifies, proceeds to perform any
associated service/authorization function.
No certificate is needed. Certificates are really targeted at
processes which can be carried out w/o regard to any additional
context and/or needing a prior business relationship (i.e. say a
server that exists solely for the purpose of performing authentication
functions ... but otherwise does absolutely nothing).
A physical world analogy to the offline use of certificates are the
old business paper checks that had signing limits (i.e. in theory the
value bound into the paper check/certificate had some meaning when the
check was being used at some offline site). As the world
simultaneously moved to both electronic as well as online, there was
never any real business requirement for a offline, electronic check
(i.e. another word for certificate) ... but went to things like
online, electronic, business purchase cards that not only supported
business rules regarding individual purchases, but also things like
aggregate purchase rules (no longer found the scam where somebody
signed 200 $5,000 checks in order to make a $1million purchase).
The issue with regard to being online ... is that if the current
business context has to be accessed (aka account record), that it is
more efficient to use a authentication process with public key &
other timely information bound in the account record; that to rely on
stale data bound possibly bound in a redundant and superfluous
certificate.
some of the attached also discusses the scenerio of a "secure" DNS
providing a public key for server authentication; vis-a-vis relying on
a server certificate. In part, most SSL server certificates supposedly
fullfil a role of adding security because of possible security
problems with the domain name infrastrucutre. However, a CA, issueing
an SSL domain name certificate, has to rely on the authoritative
agency for domain names to validate the information that will be bound
into a certificate (i.e. the domain name infrastructure, which
supposedly has the security problems justifying the certificate in the
first place). A security improvement for the domain name system
involves registering a public key at the same time the domain name is
registered. However, 1) improving domain name system so that the CA
can better trust it as the authoritative agency ... also eliminates
one of the main reasons for needing a server SSL certificate, and 2)
if the security improvement with registered public keys for the domain
name system so it can be better trusted to provide timely information,
then it can also be trusted to provide the registered public key (making
a server SSL certificate, with possibly stale information from the
past, redundant and superfluous).
random refs:
http://www.garlic.com/~lynn/aadsm2.htm#inetpki
http://www.garlic.com/~lynn/aadsm2.htm#account
http://www.garlic.com/~lynn/aepay4.htm#comcert6
http://www.garlic.com/~lynn/aepay4.htm#comcert7
http://www.garlic.com/~lynn/aepay4.htm#comcert8
http://www.garlic.com/~lynn/aepay4.htm#rfc2807b
http://www.garlic.com/~lynn/aepay4.htm#rfc2807c
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Server authentication
Newsgroups: comp.security.misc
Date: Wed, 21 Feb 2001 23:58:01 GMT
aka
... for the 99.9999999% of the current "client" authentication events
that goes on today in the internet, it is a relatively trivial upgrade
to support public key authentication w/o requiring certificates
(i.e. add digital signature authentication to radius and public key
registration option in lieu of passwords).
... for the 99.9999999% of the current "server" authentication events
(i.e. SSL domain name certificates) that goes on today in the internet
... a justification has been they are needed because of domain name
system integrity problems; however since the domain name
infrastructure is the authoritative agency that a CA has to check with
in order to validate the domain name for issuing a certificate .... it
is in the interest of CAs to improve the integrity of the doman name
infrastructure (so CAs can trust the domain name information that CAs
need to validate when issueing a certificate). The current RFCs for
improving domain name infrastructure includes registering a public key
with the registration of the domain name. However fixing integrity of
domain name system eliminates the justification for the existing SSL
domain name certificates ... as well as providing a trusted method for
the domain name infrastructure to distribute trusted public keys w/o
requiring certificates (not only are the SSL domain name certificates
no longer justified, but they also become redundant and superfluous).
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Memory management - Page replacement
Newsgroups: comp.os.misc,alt.folklore.computers
Date: 22 Feb 2001 11:24:34 -0700
Brian Inglis writes:
On Wed, 21 Feb 2001 09:53:36 -0500, "John D."
wrote:
>What is the advantage if using two-handed clock replacement policy
>than one-handed? What is the effect if second hand is closer first
>hand and in what situations operation system can do this?
Ask the guy who invented it! [xposted to a.f.c]
Thanks. Take care, Brian Inglis Calgary, Alberta, Canada
--
Brian_Inglis@CSi.com (Brian dot Inglis at SystematicSw dot ab dot ca)
use address above to reply
with one bit of reference and one-handed clock .... the amount of
"history" information represents the time that it takes for the "hand"
to make a complete cycle of all pages i.e. one-handed checks to see if
the reference bit is off, if it is off, it selects the page, if it is
on, it just turns the bit off. the bit then has the time it takes the
hand to completely cycle thru all pages for it to be turned on and
preserve the page in memory.
The whole purpose of the algorithm is hopefully to be able to
discriminate between pages that have been recently referenced and
those that haven't been recently referenced (the set of all pages with
reference bit off and the set of all pages with the reference bit on).
The algorithm has some interesting dynamic adaoptive characteristic
because as the demand for pages goes up, the interval that pages can
survive in memory decreases.
However, for various configurations ... the period of time it takes
the hand to completely cycle through all pages may be excessively
large ... and the algorithm starts to cycle with all pages having the
bit on with all pages having the bit off; i.e. the idea of the
algorithm is to be able to descriminate between pages that have been
used more recently versis pages that have been used less recently. If
the time for the one hand to cycle thru all pages is long enuf, there
may not be any descrimination capability (all pages look the same).
Two handed clock allows more degrees of latitude in the period between
the time a reference bit is turned off and the time it is examined
... while still preserving the dynamic adaptive characteristic of
single handed clock ... rather than the reset hand being exactly equal
to the total number of available pages .... the reset hand can be some
fraction of the total number of available pages. This has some degree
of more control over the interval between the time the reference bit
is turned off and the time it is examined ..... which in theory allows
better descrimination in being able to "rank" pages that have been
more recently referenced from those that have been less recently
referenced (i.e. for some environments, the single handed clock
interval, with full rotation of all pages is too long an interval to
provide any meaningful descrimination/categorization of pages into the
two groups ... they all appear to be in one group or the other).
However, both one handed & two handed clock will degenerate to
FIFO under various circumstances. There is a variation that I also did
on two-handed clock that has the interesting property of degenerating
to random ... rather than FIFO; i.e. many of the conditions where the
algorithm degenerates to FIFO is where pages are being used in a
cyclic manner and you therefor guarentee that every page will be
faulted on every cycle. Random works much better in this scenerio,
since it tends to reduce to only a random number of pages are faulted
on every cycle.
this was all 30+ years ago.
there was stanford PhD by carr on clock in the early 80s.
random refs:
http://www.garlic.com/~lynn/93.html#0
http://www.garlic.com/~lynn/93.html#4
http://www.garlic.com/~lynn/94.html#01
http://www.garlic.com/~lynn/94.html#1
http://www.garlic.com/~lynn/94.html#2
http://www.garlic.com/~lynn/94.html#4
http://www.garlic.com/~lynn/94.html#6
http://www.garlic.com/~lynn/94.html#10
http://www.garlic.com/~lynn/94.html#14
http://www.garlic.com/~lynn/94.html#49
http://www.garlic.com/~lynn/94.html#54
http://www.garlic.com/~lynn/95.html#12
http://www.garlic.com/~lynn/96.html#0a
http://www.garlic.com/~lynn/96.html#10
http://www.garlic.com/~lynn/97.html#0
http://www.garlic.com/~lynn/97.html#28
http://www.garlic.com/~lynn/98.html#2
http://www.garlic.com/~lynn/98.html#17
http://www.garlic.com/~lynn/99.html#18
http://www.garlic.com/~lynn/2000.html#86
http://www.garlic.com/~lynn/2000f.html#9
http://www.garlic.com/~lynn/2000f.html#10
http://www.garlic.com/~lynn/2000f.html#32
http://www.garlic.com/~lynn/2000f.html#33
http://www.garlic.com/~lynn/2000f.html#34
http://www.garlic.com/~lynn/2000f.html#36
note ... if this was comp.arch ... the question would assumed to be a
home work assignment .... and answering home work assignments for
other people is strickly frowned upon.
L. Belady, A Study of Replacement Algorithms for a Virtual Storage
Computer, IBM Systems Journal, v5n2, 1966
L. Belady, The IBM History of Memory Management Technology, IBM
Journal of R&D, v25n5
R. Carr, Virtual Memory Management, Stanford University,
STAN-CS-81-873 (1981)
R. Carr and J. Hennessy, WSClock, A Simple and Effective Algorithm
for Virtual Memory Management, ACM SIGOPS, v15n5, 1981
P. Denning, Working sets past and present, IEEE Trans Softw Eng, SE6,
jan80
J. Rodriquez-Rosell, The design, implementation, and evaluation of a
working set dispatcher, cacm16, apr73
D. Hatfield & J. Gerald, Program Restructuring for Virtual Memory,
IBM Systems Journal, v10n3, 1971
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Memory management - Page replacement
Newsgroups: comp.os.misc,alt.folklore.computers
Date: 22 Feb 2001 14:01:40 -0700
Anne & Lynn Wheeler writes:
note ... if this was comp.arch ... the question would assumed to be a
home work assignment .... and answering home work assignments for
other people is strickly frowned upon.
& while i was undergraduate when i did most of the work ... i never
got any homework credit for it.
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What does tempest stand for.
Newsgroups: sci.crypt
Date: Thu, 22 Feb 2001 22:19:21 GMT
admin@hotmail.com (Mark Healey) writes:
I know that "tempest" is an acronym (really T.E.M.P.E.S.T.) but I
forgot what it stands for. Surprisingly this isn't in any of the
online sources I could find.
Could someone please tell me.
Mark Healey
marknews(the 'at' thing)healeyonline.com
available number of online sources, including rfc2828
also see security glossary at
http://www.garlic.com/~lynn/secure.htm
TEMPEST
(O) A nickname for specifications and standards for limiting the
strength of electromagnetic emanations from electrical and electronic
equipment and thus reducing vulnerability to eavesdropping. This term
originated in the U.S. Department of Defense. [Army, Kuhn, Russ] (D)
ISDs SHOULD NOT use this term as a synonym for 'electromagnetic
emanations security'. [RFC2828] The study and control of spurious
electronic signals emitted by electrical equipment, such as computer
equipment. [AJP][NCSC/TG004][TCSEC] (see also approval/accreditation,
preferred products list) (includes compromising emanations,
emanations, emanations security, emission security)
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: LINUS for S/390
Newsgroups: bit.listserv.ibm-main
Date: Fri, 23 Feb 2001 16:02:48 GMT
Ted.Spendlove@THIOKOL.COM (Ted Spendlove) writes:
Bob,
You definition of "Worked fine" is a bit different than mine. The
"hot rod" 155 that you converted at the CSC center where I worked had
a mean-time-to-fail of 15 MINUTES for the first 5 days. The average
MTTF for the first 18 months was only 3 days. That early solid state
memory was really awfull!!
Ted Spendlove
ex-CSC
as an aside, the front panel of the 155 was like a door with latch
... you could unlatch & swing it open. One of the switches behind
front panel disabled the cache on the 155. Benchmarking the 155 with
cache disabled had about the same thruput as a 145.
as part of calibrating the resource manager (especially its dyanmica
adaptive characteristics), I built an automated benchmark procedure &
did a test suite of 2000 benchmarks that took about 3 months elapsed
time to run Part of the test suite was varying available memory,
processer speed, i/o capacity, and workload. Part of this was some of
the genesis for automated operator, some of the tests involved
rebuilding the kernel and then restarting the system and starting the
next workload.
Some of the workload was nominally expected ... but there were also
stress-test workloads and extreme outlayers ... like a paging intensive
workload, the most extreme version had a mean service time of 1 second
for a page fault (saturate the page i/o subsystem around 300-350 page
i/os per sec. ... and build up a queue of 300 page requests ... new
page requests would get put in the queue of 300+ and take a second to
service).
the benchmarks were also use to cross-calibrate the predictor ... the
APL analytical performance model available to the field on HONE (with
a customer workload characterization, the predictor would say stuff
about what the effects of faster cpu, more memory, or more disks would
have).
in any case, being able to run the cambridge 155 at both 155 speeds
and 145 speeds aided in the calibration process.
as a measure of the ability to dynamically adapt, a kernel
implementing an early version (along with a bunch of other changes)
had been made available to a special large customer for 145. about 10
years later the customer had a wide deployment on 3083s(?) and called
to ask about SMP support (they were still running the same
kernel/code, and for ten years it had been doing its job of
dynamically adapting to a wide range of processors speeds, available
memory, i/o configurations and workload).
random refs:
http://www.garlic.com/~lynn/94.html#2
http://www.garlic.com/~lynn/95.html#0
http://www.garlic.com/~lynn/95.html#1
http://www.garlic.com/~lynn/99.html#38
http://www.garlic.com/~lynn/99.html#149
http://www.garlic.com/~lynn/99.html#150
note the following from
http://www.garlic.com/~lynn/2001c.html#2
A small subset of this was incorporated into the product in release 3
of VM/370 called discontiguous shared segments. However, it didn't
include the memory mapped file system and/or the ability to memory map
arbritrary CMS executables/modules (including the abilility for CMS
modules to be generated with portions of the memory-mapped region
specified as shared memory ... and for CMS kernel to automatically
invoke the shared memory specification as part of invoking a CMS
executable).
also picked up at the same time was the automated operator stuff
(developed for doing automated benchmarking) at the same time for
inclusion into release 3.
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Something wrong with "re-inventing the wheel".?
Newsgroups: alt.folklore.computers,comp.os.cpm
Date: Sat, 24 Feb 2001 18:14:16 GMT
CBFalconer writes:
I considered the original PC keyboards misdesigned, because you
couldn't conveniently put a line on the CRT bottom defining their
use that matched the layout. Now such Fn key usage help is
possible but rarely implemented.
And I have since become convinced that touch key usage is more
important, but the keys have moved!
there was lot of work done on hands (not) leaving the keyboard. in the
'70s there was work on hand-sized egg/ball shapped chord-keyboard
... could have one for each hand. fingers fit into depressions with
multi-position keys at the finger tips and you could have a mouse-like
tracking ball underneath. with practice, it was relatively easy to
achieve 80 words/minute (simpler than current standard qwerty key
layout) ... and the hands never had to leave the "keybarod" to do
positioning.
problem, of course was that the qwerty stuff was/is so prevalent.
one of the early standard keyboard pointers were two sliders at the
space bar for the thumbs ... one controlled X coordinate on the screen
and the other the Y coordinate ... problem was that it required
coordinating both thumbs to position the pointer.
advances in technology allowed single small control at the junction of
the G/H/B keys (found on some laptops).
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: OS/360 (was LINUS for S/390)
Newsgroups: bit.listserv.ibm-main
Date: Sun, 25 Feb 2001 16:04:30 GMT
listmanager@SNIPIX.FREESERVE.CO.UK (Roger Bowler) writes:
Actually, OS/360 did have code to deal with control registers.
Keep in mind that the original S/370 announcement didn't include
DAT, and that two out of the three machines in the announcement
didn't even have the hardware for it. S/360 supported EC mode,
but didn't exploit it nearly as much as the AOS releases did.
as an aside, from the front panel of the system/360, model 67
reference data "blue card" (229-3174-0)
IBM System/360 Model 67 Reference Data
Floating-point Double Precision Instructions
Load Mixed LX RX R1,D2(X2,B2) 74
Add Mixed Normalized AX RX R1,D2(X2,B2) 76
Add Double Normalized ADDR RR R1,R2 26
Add Double Normalized ADD RX R1,D2(X2,B2) 66
Subtract Mixed Normalized SX RX R1,D2(X2,B2) 77
Subtract Double Normalized SDDR RR R1,R2 27
Subtract Double Normalized SDD RX R1,D2(X2,B2) 67
Multiply Double Normalized MDDR RR R1,R2 25
Multiply Double Normalized MDD RX R1,D2(X2,B2) 65
Store Rounded (Short) STRE RX R1,D2(X2,B2) 71
Store Rounded (Long) STRU RX R1,D2(X2,B2) 61
Model 67 Instruction Codes
Instruction Mnem Type Exception Code
Load Multiple Control LMC RS M, A, S, D P B8
Store Multiple Control STMC RS M, P, A, S B0
Load Real Address LRA RX M, A, S B1
Branch and Store BASR RR 0D
Branch and Store BAS RX 4D
Search List (RPQ) SLT RS P, A, S, Relo A2
Notes:
A Addressing Exception
D Data Exception
M Privileged Operation Exception
P Protection Exception
S Specification Exception.
.........................
also
control registers:
CR0 segment table register (for dynamic address translation)
CR1 unassigned
CR2 translate exception address register
CR3 unassigned
CR4 Extended Mask Registers for I/O Control Masks
CR5 unassigned
CR6 bits 0,1 Machine Check Mask Extensions for channel
controller
bits 2,3 reserved
bits 4-7 unassigned
bit 8 extended control mode
bit 9 configuration control bit, defines when
partitioning can take place
bts 10-23 unassigned
bits 24-31 external interruption masking
CR7 unassigned
CR6-14 partitioning sensing registers, see 2167 description for register
layout
CR15 unassigned
.......................................................
The card also contained the sense byte defintions for
1052/2150, 2540/1821, 1403/1443, 1442/2501/2520, 2671/2822, 2400,
2311/2841, 2301/2820, 2250, 2260, 2280, and 2282
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: database (or b-tree) page sizes
Newsgroups: comp.arch,comp.arch.storage
Date: Mon, 26 Feb 2001 16:31:48 GMT
"Bill Todd" writes:
And in that distant past that conclusion was likely correct. Disk transfer
rates were measured in KB/sec: a few hundred KB/sec wasn't bad 20 years
ago, which meant that 512 bytes took around 10 ms. to transfer, and anything
much larger began to affect I/Os/sec noticeably (since disk bandwidths have
improved much faster than seek times and rotational speed). Internal bus
bandwidths also were far smaller than today's, so larger pages tended to
saturate them. And virtual memory was less common, making large pages
harder to cache without cache fragmentation (not to mention that the memory
just to hold them was expensive as well, and at least on 16-bit machines a
precious resource due to addressing limitations).
a large percentage of the big production commercial database
operations had virtual memory 25 years ago and mbyte/sec transfer was
common ... a lot of that was upgraded to 3mbyte/sec 20 years ago. the
upgrade to 3mbyte/sec transfer started a lot of work larger
multi-block transfers ... i.e. the disks upgrade from 1mbyte/sec to
3mbyte/sec had significant more capacity under an arm w/o little or no
improvmeent in avg. arm access (i.e. it was possible to transfer 3
times as much data per avg. arm access).
long ago and far away comparison of about 35 years ago to 20 years ago:
http://www.garlic.com/~lynn/94.html#43
the above possibly represented 90+% of the business critical database
processing during the period.
virtual memory system from 20 years ago could have several thousand 4k
pages and an application could have hundreds of 4k pages. "single"
paging such an application started to make less and less sense. any
benefit from single paging such an application with 4k pages was more
than offset by the arm contention issues.
The above claimed that basically from the mid-60s to 1980, real
storage and cpu increased by a factor of 50, disk transfer increased
by a factor of 10 and avg arm access increased by a factor of 4. In
effect, by 1980, the relative system thruput of arm performance had
decreased by a factor of 10. With such a significant increase in
memory and processing speed ... and some increase in disk transfer
speed; it was possible to "waste" (trade-off) significant amounts of
cpu and real storage ... and modest amounts of disk transfer
attempting to maximize the effectiveness of each arm access.
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: database (or b-tree) page sizes
Newsgroups: comp.arch,comp.arch.storage
Date: Mon, 26 Feb 2001 20:11:43 GMT
gah@ugcs.caltech.edu (glen herrmannsfeldt) writes:
All this is for moving head disks. The first thing I remember
after I first heard of virtual storage was the 2305 fixed-head
disk. Not so big, but it had the 3MB/s transfer rate way before
1980, and no seek time. There is still latency, but rotational
position sensing (RPS) was supposed to help with that.
(I remember RPS from the 3330, I don't know if the 2305 had it.)
-- glen
in the previous reference "drums" were 2301 and then 2305 fixed head
devices (one head per track and no moving arm).
2301 was effectively a 2303 fixed head device that read/wrote 4 tracks
in parallel for approx. 1.5mbyte transfer (mid 60s). for paging, a
pair of tracks were formated with 9 4k pages.
2305 was follow-on. both 3330 and 2305 had rotational position
sensing. This wasn't so much for drive thruput ... but for multiple
device thruput sharing the same i/o channel. prior to 3330/2305, the
sequence was arm and then select record. The arm positioning operation
could be done while not making the i/o channel busy (aka multiple
concurrent operations could proceed concurrently); but the select
record operations would "busy" the channel (i.e. from the time the arm
was in position until the correct record rotated under the head). The
RPS feature allowed operations to release the channel for other i/o
operations until the correct record rotated under the head.
what 2305 had ... in addition was "multiple exposures" ... basically
instead of a single I/O request interface, the 2305 had eight logical
i/o request interfaces ... with the 2305 controller servicing the
requests in optimal hardware order (i.e. effectively could approx. out
of order execution).
There was also a "fast" 2305 with heads 180 degree offset cutting the
avg. rotational delay in half (i.e. first head that the record got to
would read it).
There was also a really special 2305 that may have only been available
on special contract from intel ... it was all electronic simulating a
2305 with no arm access and no rotational delay. it had a special
model number ... i think 1655(? or some such).
random refs:
http://www.garlic.com/~lynn/2001b.html#69
http://www.garlic.com/~lynn/2000c.html#34
http://www.garlic.com/~lynn/2000d.html#7
note RPS only helped channel busy when selecting specific record. lots
of that generation of disk used the CKD feature to search for the
correct record based on pattern match (as opposed to selecting
specific record). when doing multi-track search, the channel could be
continuously busy for as many revolutions as there were tracks in a
cylinder (or arm position). example described in the following:
http://www.garlic.com/~lynn/94.html#35
http://www.garlic.com/~lynn/93.html#29
http://www.garlic.com/~lynn/97.html#16
http://www.garlic.com/~lynn/99.html#75
some configuration comparisons
http://www.garlic.com/~lynn/95.html#8
note in the previous reference
http://www.garlic.com/~lynn/95.html#10
where i made the claim that the relative system performance of disk
had declinded by at least a factor of five over a period of 12-15
years (at the time i wrote the original), a lot of people in the disk
division got upset and they assigned a performance group to
investigate. After some study, they came to the conclusion that the
actual decline in performance was worse when the effects of RPS-miss
were taken into consideration in a large busy environment.
RPS allowed the device to give up use of the channel while the disk
was rotating but it expected to re-acquire the channel when the head
was in position. However, if the channel was busy with some other
operation, there was an RPS-miss and the disk had to perform a full
revolution and try again. This was before full-track buffers which
didn't show up until the 3880-13 disk controller about 1983 or 1984
(on the road at the intel developer's conference and don't have access
to some data ... if any body else is here, i'm on a panel at 2pm
tomorrow).
--
Anne & Lynn Wheeler | lynn@garlic.com, http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: On RC4 in C
Newsgroups: comp.lang.ada,sci.crypt,talk.politics.crypto
Date: Wed, 28 Feb 2001 05:07:57 GMT
William Hugh Murray writes:
(Notice that many already complain about the dominance and business
practices of both of these companies. We seem to have a penchant for
attributing to predatory practices the results of wise, not to say
courageous, investment and novel business models.)
Having been through this once, I have more faith in the markets and
competition than in litigation and regulation. Time will tell. In
any case, this too is a discussion for another day and another forum.
Perhaps over a glass of bubbly some time.
there was some case made regarding some execs that might have been
accused of taking a one time shot to quarterly earnings and their
bonus converting a significant number of lease machines to purchased
in the 70s.
there was also june 23rd, 1969 with the separate charging for people
services (aka unbundling; which had been packaged for "free" as part
of customer support).
following has comments supposedly attributed to testimony in the trial
http://www.garlic.com/~lynn/94.html#44
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What is "IBM-MAIN"
Newsgroups: comp.lang.asm370
Date: Fri, 02 Mar 2001 16:42:10 GMT
Tom Anderson writes:
I have been away from this environment for a while and
while reading some posts I see a reference to something
called "IBM-MAIN". Is this a newsgroup, a mailing list,
or something you subscribe to through IBM?
a bitnet listserv mailing list is also gatewayed to usenet. the
mailing list is "ibm-main" ... the usenet gatewayed group is
bit.listserv.ibm-main
--
Anne & Lynn Wheeler | lynn@garlic.com, http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Something wrong with "re-inventing the wheel".?
Newsgroups: alt.folklore.computers,comp.os.cpm
Date: Sat, 03 Mar 2001 00:11:27 GMT
some comments about re-inventing the wheel ... also implies re-inventing the
same bugs:
http://www.garlic.com/~lynn/aadsm5.htm#asrn4
on a panel discussion at:
http://www.intel94.com/idf/spr2001/sessiondescription.asp?id=stp+s13
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What is "IBM-MAIN"
Newsgroups: comp.lang.asm370
Date: Sat, 03 Mar 2001 16:08:10 GMT
Bill Becker writes:
I remember posting to the usenet version and getting the automated
nasty-grams telling me "You are not authorized to post to ... "
Finally, Darren emailed me personaly. Now all I receive is the
monthly subscription probe.
i would get the "not authorized" message ... but they stopped ... but
i also notice that lot of non-usenet don't appear to see anything i
post. possibly 18?? months ago when i stopped getting the "not
authorized" messages.
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: OS for IBM 370
Newsgroups: comp.lang.asm370
Date: Sun, 04 Mar 2001 01:59:08 GMT
lwinson@bbs.cpcn.com (lwin) writes:
IIRC, it was 29 meg per disk pack, and five disks per 2314, so you
should be able to fit it all on one unit. Of course, you won't have
space for anything else to run the company unless you have multiple
disk systems.
It just amazes how today we think 117 Meg is "nothing". In the days
that OS/360 was written, it was quite a lot.
Our S/360-40 DOS operating system required all of 16K core memory.
I'm not sure what the low end S/360 minimum memory offering was--16K,
or even 8K. Those numbers sound absurbly low today, but in those days
the 1401, the most common machine, maxed out at 16K, and many users
had smaller machines.
five spindles for a "short" 2314. A regular 2314 had 9 spindles
... only eight were addressable at any one time and a ninth
"spare". The 9-spindle 2314s had 8 addressing plugs, it was possible
to mount a new pack on the 9th drawer, bring it up to speed, and pop
out the addressing plug from one of the other drives and pop it into
the drive with the recently mounted pack.
random refs (including URL for picture of 9-drive 2314 string)
http://www.garlic.com/~lynn/2001b.html#7
random other refs:
http://www.garlic.com/~lynn/95.html#8
http://www.garlic.com/~lynn/95.html#10
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Use of ICM
Newsgroups: comp.lang.asm370
Date: Sun, 04 Mar 2001 05:24:01 GMT
"Robert L. Cochran Jr." writes:
Consider this code
L 8,ADCON1
LH 9,LENGTH1
L 2,ADCON2
LR 3,9
ICM 2,X'40'
MVCL 2,8
What is the ICM doing and why would an applications programmer want to
use it?
MVCL will use the high byte of 2 as pad character if the destination
length is longer than the source length.
x'40' is a ebcdic blank
however,
a) the icm is coded wrong
b) the mvcl has same length for source & destination (aka the lr 3,9).
icm should be something like
icm 2,b'1000',=x'40'
i.e. take the data at storage location =x'40' and load it into high
byte of register 2.
i would hope that the assembler would generate an error for the above
icm since there is no 3rd argument ... & with the x'40' as the 2nd
argument, it is likely that it takes it to mean the 2nd byte of
register 2, not the first byte.
icm also sets the condition code based on whether the loaded value(s)
were zero or non-zero i.e. can be used in place of load followed by ltr if
just interested in zero/non-zero c.c.
icm 8,b'1111',adcon1
bz error
icm 2,b'1111',adcon2
bz error
would test to see if adcon1 & adcon2 are zero
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Use of ICM
Newsgroups: comp.lang.asm370
Date: Sun, 04 Mar 2001 05:56:49 GMT
"Robert L. Cochran Jr." writes:
Consider this code
L 8,ADCON1
LH 9,LENGTH1
L 2,ADCON2
LR 3,9
ICM 2,X'40'
MVCL 2,8
and besides it is the wrong reg, the pad byte goes in the high byte of
the source length (aka register 9) ... only 24 bits are used in the
source and destination length registers.
one might also do a SR 9,9 and an icm,b'0011',length1 with a branch.
so possibly (if there were any chance of source length being less than
destination length).
icm 8,b'1111',adcon1
bz error
icm 2,b'1111',adcon2
bz error
sr 9,9
icm 9,b'0011',length1
bz error
lr 3,9
icm 9,b'1000',=c' '
mvcl 2,8
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Use of ICM
Newsgroups: comp.lang.asm370
Date: Sun, 04 Mar 2001 06:04:13 GMT
Anne & Lynn Wheeler writes:
icm 8,b'1111',adcon1
bz error
icm 2,b'1111',adcon2
bz error
sr 9,9
icm 9,b'0011',length1
bz error
lr 3,9
icm 9,b'1000',=c' '
mvcl 2,8
as an aside, questions like this posted to comp.arch are treated as if
somebody is trying to get their homework done for them ...
random recent refs:
http://www.garlic.com/~lynn/2001.html#70
http://www.garlic.com/~lynn/2001b.html#38
http://www.garlic.com/~lynn/2001c.html#11
http://www.garlic.com/~lynn/2001c.html#10
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The Foolish Dozen or so in This News Group
Newsgroups: alt.hacker,sci.crypt
Date: Sun, 04 Mar 2001 07:06:25 GMT
"Scott Fluhrer" writes:
And, of course, you have the problem that Gwyn (?) cited that disk drives
often write bits to parts of the drive without you asking it to. Being
careful with your fopen() and your fclose() functions won't help you there
either.
it may be possible to use some form of async i/o with raw read/write,
note however that disk electronics criteria for a write tend to be
more demanding than a read ... a write failure and system (or even
controller) re-allocation of a block to a new physical disk sector
doesn't necessarily mean that the original physical disk record is
unreadable. disk sparing with a bad spot can take several seconds as
it tries to find good spare spots.
couple URLs alta-vista found on (sector & record) sparing
http://til.info.apple.com/techinfo.nsf/artnum/n24530
http://www.eros-os.org/design-notes/DiskFormatting.html
http://docs.rinet.ru:8080/UNT4/ch28/ch28.htm
http://mlarchive.ima.com/winnt/1998/Nov/2142.html
misc. words from scsi standard
Any medium has the potential for defects which can cause user data
to be lost. Therefore, each logical block may contain information
which allows the detection of changes to the user data caused by
defects in the medium or other phenomena, and may also allow the data
to be reconstructed following the detection of such a change. On some
devices, the initiator has some control some through use of the mode
parameters. Some devices may allow the initiator to examine and
modify the additional information by using the READ LONG and WRITE
LONG commands. Some media having a very low probability of defects
may not require these structures.
Defects may also be detected and managed during execution of the
FORMAT UNIT command. The FORMAT UNIT command defines four sources of
defect information. These defects may be reassigned or avoided during
the initialization process so that they do not appear in a logical
block.
Defects may also be avoided after initialization. The initiator
issues a REASSIGN BLOCKS command to request that the specified logical
block address be reassigned to a different part of the medium. This
operation can be repeated if a new defect appears at a later time.
The total number of defects that may be handled in this manner can be
specified in the mode parameters.
Defect management on direct-access devices is usually vendor
specific. Devices not using removable medium typically optimize the
defect management for capacity or performance or both. Devices that
use removable medium typically do not support defect management (e.g.,
some floppy disk drives) or use defect management that is based on the
ability to interchange the medium.
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Massive windows waisting time (was Re: StarOffice for free)
Newsgroups: alt.folklore.computers
Date: Sun, 04 Mar 2001 17:34:53 GMT
ab528@FreeNet.Carleton.CA (Heinz W. Wiggeshoff) writes:
Thank you for letting me get that off my chest. Now, I'd like to see
someone bring in a console with all the blinkenlichts from an IBM
360 model 40 through 85. (Never saw a higher model number.) Now THAT
I'd bid on.
there was 195 ... tales that if "lamp test" was performed, fuse could
blow ... i believe there has been thread that dummy ones have been
used in movies (no computer, just front panel hooked up to something
that would blink the lights). san jose research had one.
feb 30th?
random refs on 360/195
http://www.cs.clemson.edu/~mark/acs_technical.html
http://csep1.phy.ornl.gov/ov/node12.html
http://www.cs.ucl.ac.uk/research/darpa/internet-history.html
http://www.crowl.org/Lawrence/history/computer_list
http://www.cmc.com/lars/engineer/comphist/model360.htm
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The Foolish Dozen or so in This News Group
Newsgroups: alt.hacker,sci.crypt
Date: Sun, 04 Mar 2001 23:22:02 GMT
"Douglas A. Gwyn" writes:
Wrong. It is possible to ensure that the same disk blocks will
be ovrwritten (unless a new bad block gets added to the remapping
table during the process), but you have to open the file in a
particular mode (r+w in stdio terminology); if the file is opened
for writing in the default mode, it gets truncated to 0 length and
all its previous data blocks are returned to the block-buffer pool.
It is quite common for different disk blocks to get assigned as the
new file grows.
however, overwriting 27 times is a little harder since straightforward
overwrite is likely to just be updating buffer records. frequently
multiple overwriting passes consists of different combinations of ones
& zeros with the intent of exercising the magnetic flux in different
ways on the disk surface.
there is some chance (in unix) of issuing fsck a couple times and
waiting a minute or so between passes.
of course even this changes if you are dealing with log-structured
filesystem ... which attempts to always write to a new location.
random ref:
http://www.garlic.com/~lynn/2000.html#93
for many of these scenerios it just about boils down to some
filesystem enhancement that meets some zeroization standard when
blocks are released (and uses sequences of patterns that satisfy some
criteria based on knowledge of magnetic properties of disk surface).
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: mini-DTR tapes? (was Re: The longest thread ever ...)
Newsgroups: alt.folklore.computers
Date: Mon, 05 Mar 2001 02:07:17 GMT
Eric Smith <eric-no-spam-for-me@brouhaha.com> writes:
What's a "mini-DTR" tape?
small 9track tape reel holding <<2400' of tape. all the ones i saw
were cheap gray plastic ... 100' (to maybe 200' max) of tape. reel
diameter was maybe 1" larger than the hole in the middle for the hub
(i.e. say maybe 1/2" of gray plastic).
next size up held maybe up 600' of tape and typically actually came
in a case (the gray plastic reels didn't have a case and tape was kept
from spilling off the reel with rubber band or very smooth strip of
plastic). the 600' reels may have been 1/2 the diameter of a standard
2400' tape reel.
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: PKI and Non-repudiation practicalities
Newsgroups: sci.crypt
Date: Mon, 05 Mar 2001 21:44:00 GMT
"Lyalc" writes:
No one buys security. They do pay for things that improve their business,
short and long term.
PKI merely replicates password based processing. Remember, the private key
is controlled by a password. So a digital signature is merely an indication
that someone once knew the password associated with a certificate/private
key. And that the password was verified on a remote machine with no
specific indication of that machine's trustworthiness . Nothing more.
Many billions of dollars in transactions are authenticated today by
passwords (e.g. ATMs with PINs) with very low technology based risk
exposure.
What else is requered depends upon your goals. Secure password capture,
secure private key storage, secure processing, high bandwidth and large
storage are some criteria that spring to mind for day to day electronic
signatures.
Lyal
i would have said that public/private key authentication does a little
bit better job than secret-key/pin authentication .... since it
eliminates some issues with the sharing of a secret-key.
hardware tokens can be accessed with pin/secret-key and then do
public/private key digital signatures for authentication ... but there
is no "sharing" of the pin/secret-key.
taken to the extreme, biometrics is a form of secret key .... and
while compromise of pin/secret-key in a shared-secret infrastructure
involves issuing a new pin/secret-key ... current technology isn't
quite up to issuing new fingers if a biometric shared-secret were
compromised (aka there are operational differences between
shared-secret paradigms and non-shared-secret paradigms ... even if
both have similar pin/secret-key/biometrics mechanisms).
in an account-based infrastructure that already uses some form of
authentication (pins, passwords, mothers-maiden-name, #SSN, etc), it
is relatively straight-forward technology upgrade to public/private
key authentication ... w/o requiring business process dislocation that
many PKIs represent.
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: database (or b-tree) page sizes
Newsgroups: comp.arch
Date: Mon, 05 Mar 2001 21:59:22 GMT
shocking@houston.rr.com (Stephen Hocking) writes:
There was a study done and written up in the relevant IEEE journal
by a Jerry Breecher(?) who took an office app running on the Data General
machines of that time and profiled it. He then tried various ways of
repacking the shared libraries and measured the paging activity caused by a
standard run. There were some rather fancy algorithms tried but it turned
out that simply laying out the functions in order of CPU usage (as measured
by the flat profile of gprof) provided most of the benefits (reduced paging
activity).
cambridge did something similar in the early '70s ... among other
things it was used to help develop new garbage collector for APL in a
virtual memory environment and also used by some of the other software
subsystem products (like used for optimizing IMS structure).
D. Hatfield & J. Gerald, Program Restructuring for Virtual Memory,
IBM Systems Journal, v10n3, 1971
and in the mid-70s a product called VS/Repack based on the work was
released (given large multiple csect/module program it would make a
pass at automatic program restructuring).
recent ref to some paging stuff in a.f.c
http://www.garlic.com/~lynn/2001c.html#10
and ref from comp.arch:
http://www.garlic.com/~lynn/93.html#4
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: How Commercial-Off-The-Shelf Systems make society vulnerable
Newsgroups: comp.security.misc,sci.military.moderated,sci.military.naval
To: sci-military-moderated@moderators.isc.org
Date: Mon, 05 Mar 2001 16:02:55 GMT
John Doe writes:
The unreflected use of Commercial-Off-The-Shelf Systems in essential
infrastructures creates unecessary risks for the modern society. Instead
of spending to defend against "rogue nations who want to commit suicide
by lobbing missiles", we should better procure systems provably
survivable against an information attack. I have written a document on
that, which you can find at http://geocities.com/fgerlach.geo/COTS.html.
note that some of this isn't necessarily specific to all COTS ... in
the case of buffer exploits, we've claimed that the problem has been
common buffer & string semantics in C programs ... i.e. vulnerability
analysis in the late '80s specifically identified C buffer & string
semantics as likely to increase buffer related problems by possibly
two orders of magnitude (aka non-C language & infrastructures with
explicit length paradigms tend to have significantly lower buffer
related problems).
randem refs:
http://www.garlic.com/~lynn/aadsm5.htm#asrn4
http://www.garlic.com/~lynn/aadsm5.htm#asrn1
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: database (or b-tree) page sizes
Newsgroups: comp.arch
Date: Tue, 06 Mar 2001 15:06:42 GMT
Anne & Lynn Wheeler writes:
and in the mid-70s a product called VS/Repack based on the work was
released (given large multiple csect/module program it would make a
pass at automatic program restructuring).
there were two methods of capturing CPU & storage refs for input
... one was full instruction simulation which caught all instruction
and data references. This was useful in identifying things like the
(virtual memory) problem with APL garbage collect ..
random refs:
http://www.garlic.com/~lynn/93.html#5
http://www.garlic.com/~lynn/94.html#7
http://www.garlic.com/~lynn/99.html#20
http://www.garlic.com/~lynn/2000g.html#30
the other method was a modification of the virtual memory system for
data collection. max. limit was specified for a process (say like 10
pages), the program was run until it had a page fault that required
more than the limit, all the valid virtual page numbers were then
output/recorded along with the accumulated cpu consumption, all the
pages invalidated (but not necessarily removed from memory), and the
application restarted (since the pages removed around in memory,
although invalid, the major overhead was the additional page faults).
This also had the advantage of obtaining both instruction and data
refs. Various calibration and tests (especially for large programs)
showed that it was a relatively close approximation to full
instruction method of storage ref. capture.
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: PKI and Non-repudiation practicalities
Newsgroups: sci.crypt
Date: Tue, 06 Mar 2001 15:30:19 GMT
"Lyalc" writes:
Not sure I, or the GAO agrees with that in all cases. The recent GAO report
(Advances and Remaining Challenges to Adoption of Public Key Infrastructure
Technology, GAO-01-277) outlines some enormous cost and complexity
challenges. $170m merely to make a few legacy applications operate with PKI
seems a lot, when the PKI itself stills needs to be built.
I would expect many are legacy systems that lack authentication
... claim was for legacy applications that currently have some form of
authentication process. The estimate is that the cost of replacing
current shared-secret authentication is well under 5% of the cost of
the legacy system i.e. a $500m legacy system would possibly cost $25m
to modify for public key authentication ... the majority of that tends
to be because of various Q&A and integration issues, if the
modification can be merged into some ongoing modification cycle, that
could further be reduced.
the issue tends to be that a front-end PKI for pilots and test
... involving a small number of accounts can be shown to be less
costly than modifying the production system and business processes
... especially if there are various kinds of risk acceptance having
the PKI information out of synch with the production account
information.
There tends to be a trade-off attempting to scale to full production
where the costs of a duplicate PKI account-based infrastructure has to
be evolved to the same level as the production account-based
infrastructure ... along with the additional business processes
maintaining consistency between the PKI accounts and the production
accounts. Full scale-up might represent three times the cost of the
base legacy infrastructure, rather than <5% of the legacy
infrastructure.
That is independent of the costs of a hardware token ... which could
be the same in either an account-base deployment or a PKI-based
deployment (and i'm working hard at making the costs of producing such
a token as low as possible while keeping the highest possible
assurance standard). There is a pending $20b dollar upgrade issue for
the existing ATM infrastructure that is going to be spent anyway
(because of the DES issue). When that is spent, the difference between
whether or not public-key support is also included in the new swap-in
is lost in the noise of the cost of the overall swap. Existing ATM
problem is further confounded that there are master DES keys in
addition to the individual DES-key infrastructure (representing
significant systemic risks, similar to CA root keys) ... the back-end
cost savings with elimination of systemic risk and shared-secrets more
than offset the incremental front-end costs of adding public key
technology in a swap-out that is going to have to occur anyway.
A trivial example would be RADIUS ... which possibly represents
99.999999% of existing client authentication events around the world
on the internet. A public-key upgrade to RADIUS is well under a couple
hundred thousand ... resulting in a RADIUS that supports multiple
concurrent methods of authentication with the connecting authority be
able to specify authentication protocol on an account by account
basis.
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: How Commercial-Off-The-Shelf Systems make society vulnerable
Newsgroups: comp.security.misc,sci.military.naval
Date: Tue, 06 Mar 2001 15:40:02 GMT
Frank Gerlach writes:
You are right that OS390 is mostly written in assembler and HP's MPE in
Pascal, but they
aren't exactly the sexy systems the DoD people want to use....
except for the length semantic problems in strings and I/O operations,
the incidence of buffer problems would be much lower than incidence of
dangling pointers and storage cancers.
the use of either explicit lengths and/or instantiated lengths (under
the covers) in string libraries and I/O operations could go a long way
to achieving that goal.
in the case of os390 ... it isn't a case of assembler ... or pls or
pli, etc ... it is convention of explicit length semantics in the
system. the i/o services from the highest level down to the hardware
implementation uses explicit lengths or instantiated lengths (under
the covers) ... so that many types of buffer problems either don't
occur or are prevented at runtime (one way or another the i/o routines
typically know the max. length of the buffer, either exlicitly in the
i/o call or by instantiated length built into the buffer).
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: How Commercial-Off-The-Shelf Systems make society vulnerable
Newsgroups: comp.security.misc,sci.military.naval
Date: Tue, 06 Mar 2001 16:04:26 GMT
Anne & Lynn Wheeler writes:
in the case of os390 ... it isn't a case of assembler ... or pls or
pli, etc ... it is convention of explicit length semantics in the
system. the i/o services from the highest level down to the hardware
implementation uses explicit lengths or instantiated lengths (under
the covers) ... so that many types of buffer problems either don't
occur or are prevented at runtime (one way or another the i/o routines
typically know the max. length of the buffer, either exlicitly in the
i/o call or by instantiated length built into the buffer).
random ref. from long ago & far away ... when i was an undergraduate I
had done the implementation for tty devices and taken a short-cut
using some one byte operations because the max. hardware transfer for
tty devices was 72 characters. this was picked up and incorporated by
the vendor in the standard product.
subsequently one customer acquired an ascii device (I think a plotter
than simulated tty interface) that had transfers much longer than 72
characters. They patched the system to increase the maximum transfer
limit to 1000(? bytes ... but didn't pick up on some of the operations
involving one byte numbers (aka 0-255). They recorded a couple dozen
system failures in a single day because of the resulting buffer
problem.
random ref:
http://www.multicians.org/thvv/360-67.html
http://www.garlic.com/~lynn/2000.html#30
it is still possible to have basic programming errors that give rise
to buffer problems ... but nothing like the numbers that are currently
experienced
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: database (or b-tree) page sizes
Newsgroups: comp.arch
Date: Tue, 06 Mar 2001 17:12:26 GMT
Bernd Paysan writes:
But in case of a credit card business, I suppose banks know pretty good
how many credit card customers they have now, and how the market is
evolving within the next 5 years.
total aside ... much of the credit card business now is merges and/or
out-sourcing. there tends to be large conversion process. also while
the basic account part is somewhat regular, keeping the actual
transactions indexed is interesting with a very large number of daily
inserts ... and large variance in number of transactions per account.
airlines is even more interesting ... since there isn't any ongoing
relationships ... just large numbers of new PNR (passenger name
records) every day. Even if you only keep six months online ... there
are all the new inserts every day ... plus approx. the same number of
deletes for the cleaning of aged-out records. A typical system might
have hundreds of thousands of PNR inserts and similar number of
deletes every day ... in addition to all the nominal query/update
activity.
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: How Commercial-Off-The-Shelf Systems make society vulnerable
Newsgroups: comp.security.misc,sci.military.naval
Date: Tue, 06 Mar 2001 18:11:07 GMT
Anne & Lynn Wheeler writes:
note that some of this isn't necessarily specific to all COTS ... in
the case of buffer exploits, we've claimed that the problem has been
common buffer & string semantics in C programs ... i.e. vulnerability
analysis in the late '80s specifically identified C buffer & string
semantics as likely to increase buffer related problems by possibly
two orders of magnitude (aka non-C language & infrastructures with
explicit length paradigms tend to have significantly lower buffer
related problems).
note this wasn't so much specific to C ... one of the other random
efforts was having produced a widely-used problem determination tool
in the early '80s and spending a lot of time characterising/profiling
problems.
a very fundamental issue turned out to be semantics and paradigms that
relied on implicit conventions. The prediction with regard to buffers
& strings in C was based on vulnerability analysis identifying common
buffers/strings was based on implicit paradigm/semantics.
explicit &/or instanstiated tends to create higher level awareness of
the issues with programmers ... so the problems just don't show up
and/or runtime processes that take explicit information into account
that handles situations.
i.e. it wasn't hindsight ... it was an issue of recognizing a major
contributor to flaws is implicit (vis-a-vis explicit).
random other refs:
http://www.garlic.com/~lynn/94.html#11
there is sometimes a trade-off between complexity and implicit. While
complexity is also a major contributor to flaws ... if explicit has to
be sacrificed in favor of simplicity ... then something needs to be
explicitly instantiated underneath the covers.
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: PKI and Non-repudiation practicalities
Newsgroups: sci.crypt
Date: Tue, 06 Mar 2001 20:57:28 GMT
"Lyalc" writes:
I've always taken the view that non-repudiation, at a commercial level, is
implementation dependent, regardless of the underlying technology.
Certificates/PKI use a shared 'secret' such as a password or biometric
The 'weakest link' rule means that shared-secrets/passwords are the thing to
focus on for really getting PKI secure, even after the expertise devoted to
PKI comes up with the answer to the PKI part of the puzzle.
pins/passwords/biometrics for activating a hardware token is significantly
different from pins/passwords/biometrics used as shared-secrets.
it is possible to do 3-factor authentication with no shared-secret
1) something you have
2) something you know
3) something you are
using hardware token that requires both pin & biometric .... where the
business process of a pin activated card is significantly different
from a business process shared-secret PIN (even if they are both PINS).
hardware token with a pin & biometric requirement can be used to meet
3-factor authentication ... and a shared-secret secret doesn't exist.
and doing it w/o impacting the business process infrastructure
.... separate issue from impacting the technology implementation;
pilots tend to be technology issues ... real deployment frequently are
business process issues.
similar discussion in sci.crypt from last oct:
http://www.garlic.com/~lynn/2000e.html#40
http://www.garlic.com/~lynn/2000e.html#41
http://www.garlic.com/~lynn/2000e.html#43
http://www.garlic.com/~lynn/2000e.html#44
http://www.garlic.com/~lynn/2000e.html#47
http://www.garlic.com/~lynn/2000e.html#50
http://www.garlic.com/~lynn/2000e.html#51
http://www.garlic.com/~lynn/2000f.html#0
http://www.garlic.com/~lynn/2000f.html#1
http://www.garlic.com/~lynn/2000f.html#14
http://www.garlic.com/~lynn/2000f.html#15
http://www.garlic.com/~lynn/2000f.html#2
http://www.garlic.com/~lynn/2000f.html#22
http://www.garlic.com/~lynn/2000f.html#23
http://www.garlic.com/~lynn/2000f.html#24
http://www.garlic.com/~lynn/2000f.html#25
http://www.garlic.com/~lynn/2000f.html#3
http://www.garlic.com/~lynn/2000f.html#4
http://www.garlic.com/~lynn/2000f.html#7
http://www.garlic.com/~lynn/2000f.html#8
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: PKI and Non-repudiation practicalities
Newsgroups: sci.crypt
Date: Tue, 06 Mar 2001 21:00:50 GMT
"Lyalc" writes:
Yep, there is a massive phase out challenge for the migration away from
single DES to 3DES or AES.
or public key ... the cut-over costs are effectively the same for
single solution or multi-solution cut-over deployment. hardware token
card with digital signatures can actually reduce various
infrastructure costs associated with shared-secret activites (again a
hardware token requiring a PIN is done w/o having the PIN a
shared-secret).
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: PKI and Non-repudiation practicalities
Newsgroups: sci.crypt
Date: Tue, 06 Mar 2001 21:32:21 GMT
Anne & Lynn Wheeler writes:
or public key ... the cut-over costs are effectively the same for
single solution or multi-solution cut-over deployment. hardware token
card with digital signatures can actually reduce various
infrastructure costs associated with shared-secret activites (again a
hardware token requiring a PIN is done w/o having the PIN a
shared-secret).
from various AADS & X9.59 writings at
http://www.garlic.com/~lynn/
take the fully loaded existing costs of sending out a new magstripe
card. the incremental costs of injecting a chip into that card is
somewhere between 10% and 50% of the fully loaded costs of turning out
a new card.
given the chip has the characteristics of a hardware token and doesn't
implement shared-secrets ... then the financial requirement for
needing a unique magstripes with unique shared-secrets is alleviated
(i.e. shared-secrets are not being divulged to different financial and
commercial organizations).
with x9.59 for all electronic retail transactions ... then
theoritically, a single hardware token performing digitally signed,
x9.59 authenticated transactions ... would not have a financial
security issue if the token were used for multiple different accounts,
potentially leading to a reduction in the number of cards shipped
(because the infrastructure has switched away from shared-secret
... even if the token is PIN activated).
furthermore, in the current credit card world, "expiration date" is
used as sort of an authentication code (i.e. you can randomly guess a
credit card number with some realistic chance of it being valid
.... also guessing the corresponding expiration date is much lower
probability). a hardware token supporting authenticated (x9.59)
transactions minimizes the requirement that an expiration date needs
to be carried on the card as a kind of authentication code.
Given that the incremental cost of injecting a chip into an existing
card delivery business process is at <100% than the current fully
loaded costs, then if the chip can be used to eliminate at least one
other card delivery ... there is a net savings to the infrastructure.
If the
1) ATM swap-out costs have no negligable difference in the cost of
the kind of technology and/or number of technologies supported
2) and if the backend costs can be significantly reduced by moving to
a non-shared-secret infrastructure
3) and if the elimination of shared-secrets and/or other chip related
characteristics reduces the number of cards that have to go out
then there is net reduction in business costs .... independent of
issues related to fraud reduction with the migration to better
authenticated transactions ... and independent of any non-repudiation
cost reduction issues.
i.e., by appropriately applying technology to basic business processes
there is opportunities for cost reduction.
This approach is completely different from one that might look at the
total costs of deploying hardware tokens and authentication technology
as part of a brand new infrastructure, totally unrelated to any
existing business purpose (not how much more it costs, but how much
less it costs).
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: PKI and Non-repudiation practicalities
Newsgroups: sci.crypt
Date: Wed, 07 Mar 2001 15:04:20 GMT
Benjamin Goldberg writes:
Even if your authentification is via a token, which in turn is activated
via biometrics, there still is a secret. It's the data in the token!
If all tokens were identical (allowing for them needing different
biometrics to activate), they would be useless. The token needs to
contain something to uniquely identify it electronically, and
authenticate that identity. Identification is simple; give each token a
unique id. Authentification, however, requires some sort of secret --
either a private key, or a shared-secret.
The weakest link is still access to the secret. An attacker merely
needs to get access to a token and open it up, and avoid the tamper
resistance, and he has the secret. This is conceptually no different
from beating a password out of the user with a rubber hose.
the difference is whether the secret is known by only one person or a
lot of people (i.e. which also represents the semantic difference
between "secret" and shared-secret).
in the shared-secret scenerios ... the shared-secret are
registered someplace and are subject to harvesting ... aka effectively
credit card numbers are treated as shared-secrets (witness all the
stuff written about protecting master credit-card databases at
merchant servers). Harvesting of master database files of
shared-secrets is significantly simpler than defeating tamper-evident
and/or beating somebody with rubber hose.
eliminating shared-secrets was the point of the discussion ... and
distinquishing shared-secret infrastructures vis-a-vis secret
infrastructures, along with the difference in fraud ROI; aka a
scenerio where somebody can electronically steal 100,000 shared-secrets in a couple of minutes ... vis-a-vis taking hrs to steal one
secret significantly changes the risk, exploit, and fraud
characteristics of an infrastructre. If it is possible to deploy a
"secret" infrastructure for approximately the same cost as a
shared-secret infrastructure and the "secret" infrastructure reduces
the fraud ROI by five to ten orders of magnitude (i.e. it takes a
thousand times as much effort to obtain 1/100000 useable fraudulant
material).
> --
> The difference between theory and practice is that in theory, theory and
> practice are identical, but in practice, they are not.
random ref
http://www.garlic.com/~lynn/2000b.html#22
the other part of the scernio ... is financial and various other
commercial infrastructures strongly push that in shared-secret
scenerios that the same shared-secret can't be shared across multiple
different organizations with multiple different objectives i.e. an
employer typically has strong requlations against "sharing" a
corporate access password shared-secret with other organizations (i.e.
using the same shared-secret password to access the corporate intranet
as is used to access a personal ISP account and misc. random
webservers around the world).
I would guess that a gov. agency would not be too please if an
gov. agency employee specified their employee access (shared-secret)
password ... as an access (shared-secret) password for some webserver
registration site in some other country.
However, it is possible to specify a public key in multiple places and
employees of one organization couldn't use the harvesting of the
public keys at that organization for penetration of other
organizations.
Furthermore, the rubber-hose approach is going to take quite a bit
longer to obtain a million secrets and hardware tokens that correspond
to the registered public keys (as compared to some of the
shared-secret harvesting techniques). Lets say that the rubber-hose
approach takes something like two days per ... planning, setup,
capture, executing, etc and involves minimum of two people. That is
four person days per secret. For a million secrets using the rubber
hose method, it then takes four million person days, or 10,959 person
days. By comparison some of the shared-secret harvesting techniques
can be done in a couple person weeks for a million shared-secrets.
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: PKI and Non-repudiation practicalities
Newsgroups: sci.crypt
Date: Wed, 07 Mar 2001 15:07:58 GMT
"Lyalc" writes:
True, although operating support costs may theoretically be double or more,
since the legacy method can't be switched off anytime soon, at least until
the whole world comes into a steady, single state condition. Esxpecially
for payment cards.
the card/crypto part of the operating costs is rather trivial part of
the overall operating & total business process costs. biggest issue is
the deployment of technology in such a way that old & new technologies
can concurrently co-exist during the transition phase, while all
technologies continue to utilize the same operating & business process
infrastructures.
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: PKI and Non-repudiation practicalities
Newsgroups: sci.crypt
Date: Wed, 07 Mar 2001 15:19:17 GMT
Anne & Lynn Wheeler writes:
four person days per secret. For a million secrets using the rubber
hose method, it then takes four million person days, or 10,959 person
days. By comparison some of the shared-secret harvesting techniques
oops, that should be 10,959 person years with the rubber hose method
compared to possibly a couple person weeks to come up with approx. the
same potential fraud "yield".
sort of reminds me of the inverse of the story about why telephones
and automobiles were never going to take off in the market ... both
required the services of manual people operators. the solution in both
cases was to make each individual person their own operator
(i.e. rather than having to hire telephone operators and automobile
drivers, each person was responsible for their own). The person hour
projections for the number of telephone operators and automobile
drivers were at least similar to the rubber-hose solution to solving
the fraud yield/ROI problem with a transition from a shared-secret
infrastructure to a secret infrastructure (with tokens and public
keys).
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: PKI and Non-repudiation practicalities
Newsgroups: sci.crypt
Date: Wed, 07 Mar 2001 16:58:23 GMT
junk@nowhere.com (Mark Currie) writes:
The attack that you make on shared-key systems is not entirely fair
though. Although it may be possible to crack the central repository
of shared-secrets/credit card numbers, PKI has a similar problem in
that if you compromise a CA, or worse, a root CA, you can create
millions of new certificates using existing identities that you can
now masquerade. The way PKI solves this is to suggest that you place
your root CA in a bunker (possibly under a mountain!) and in fact have
multiple instances scattered around the world. This increases the cost
of PKI. In an earlier thread you mentioned the possible savings to be
gained by having chip cards (shared across institutions). This may
outweight the associated infrastructure costs but I don't think that
PKI infrastructure costs are insignificant. Even if you just focus on
the CA's, hierachical PKI's tend to create a central trust point (root
CA) that millions of certs rely on. Typically a lot more users rely on
the central point than what you would find in shared-secret
systems. This puts enormous pressure on the security of this
entity. If the root CA (plus copies) are attacked by an organised
para-military group, the whole trust chain collapses because you can't
be sure that the private key wasn't compromised in the
process. Preventing these types of attack are not cheap.
Mark
I'm not talking about PKI, CA's or the certification authority digital
signature model (CADS model) ... i'm talking about the AADS (account
authority digital signature) model. It eliminates the systemic risks
inherent in the CADS model.
random refs to the AADS model can be found at:
http://www.garlic.com/~lynn
I take a infrastructure that currently registeres shared-secrets and
instead register public keys. No business process costs ... just some
technology costs.
Given that many back-end systems have some pretty strigent security
and audit requirements specifically targeted at preventing things like
insiders harvesting shared-secrets .... some of those procedures and
associates costs can be alliviated.
Also, in the ISP world ... a significant costs is service call
associated with handling a password compromise. This is further
aggravated by human factors issues with people having to track &
remember a large number of different shared-secrets ... because of the
guidelines about not using the same shared-secrets in multiple
different domains.
i.e. the start of my co