List of Archived Posts
2004 Newsgroup Postings (12/5 - 12/31)
- Single User: Password or Certificate
- Systems software versus applications software definitions
- [Lit.] Buffer overruns
- [Lit.] Buffer overruns
- [Lit.] Buffer overruns
- [Lit.] Buffer overruns
- XML Data Model
- [Lit.] Buffer overruns
- [Lit.] Buffer overruns
- [Lit.] Buffer overruns
- [Lit.] Buffer overruns
- [Lit.] Buffer overruns
- [Lit.] Buffer overruns
- [Lit.] Buffer overruns
- [Lit.] Buffer overruns
- [Lit.] Buffer overruns
- [Announce] The Vintage Computer Forum
- [Lit.] Buffer overruns
- PR/SM Dynamic Time Slice calculation
- Tru64 and the DECSYSTEM 20
- Systems software versus applications software definitions
- Tru64 and the DECSYSTEM 20
- Tru64 and the DECSYSTEM 20
- 1GB Tables as Classes, or Tables as Types, and all that
- Tru64 and the DECSYSTEM 20
- Question on internal/external IPs
- [Lit.] Buffer overruns
- 1GB Tables as Classes, or Tables as Types, and all that
- [Lit.] Buffer overruns
- Two Fedora Core 2 problems
- High Level Assembler for MVS & VM & VSE
- Integer types for 128-bit addressing
- Amusing acronym
- Listserv for TCPIP
- [Lit.] Buffer overruns
- [Lit.] Buffer overruns
- CAS and LL/SC
- A Glimpse into PC Development Philosophy
- CAS and LL/SC
- CAS and LL/SC
- Tru64 and the DECSYSTEM 20
- How many layers does TCP/IP architecture really have ?
- browser without "padlock" secure?
- [Lit.] Buffer overruns
- How many layers does TCP/IP architecture really have ?
- C v. Ada
- [Lit.] Buffer overruns
- [Lit.] Buffer overruns
- [Lit.] Buffer overruns
- creat
- [Lit.] Buffer overruns
- [Lit.] Buffer overruns
- [Lit.] Buffer overruns
- [Lit.] Buffer overruns
- FC3 sound
- creat
- CAS and LL/SC (was Re: High Level Assembler for MVS & VM & VSE)
- high speed network, cross-over from sci.crypt
- CAS and LL/SC (was Re: High Level Assembler for MVS & VM & VSE)
- CAS and LL/SC (was Re: High Level Assembler for MVS & VM & VSE)
- Will multicore CPUs have identical cores?
- will there every be another commerically signficant new ISA?
- will there every be another commerically signficant new ISA?
- creat
- Will multicore CPUs have identical cores?
- Will multicore CPUs have identical cores?
- Will multicore CPUs have identical cores?
- Integer types for 128-bit addressing
- Will multicore CPUs have identical cores?
- Organizations with two or more Managers
- CAS and LL/SC
- will there every be another commerically signficant new ISA?
- IUCV in VM/CMS
- Athlon cache question
- [Lit.] Buffer overruns
- [Lit.] Buffer overruns
- Athlon cache question
- Athlon cache question
- [Lit.] Buffer overruns
- Athlon cache question
- [Lit.] Buffer overruns
- [Lit.] Buffer overruns
- [Lit.] Buffer overruns
- [Lit.] Buffer overruns
- [Lit.] Buffer overruns
- The TransRelational Model: Performance Concerns
- Organizations with two or more Managers
Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Single User: Password or Certificate
Newsgroups: comp.security.ssh
Date: Sun, 05 Dec 2004 13:35:10 -0700
re:
http://www.garlic.com/~lynn/2004p.html#60 Single User: Password or Certificate
for a little more topic drift, i recently saw a demo of the lexus
smartkey, basically if you have it in your pocket ... it lets you open
a (locked) door and turn the ignition. basically it is as much a
form of
• something you have
authentication ... as a regular key. one issue is that it is a lot
larger (and integrated into the remote unlock token). i have no idea
if it is easier or harder to counterfeit than regular key.
basically passwords have been form of
• something you know
authentication and also a shared-secret
http://www.garlic.com/~lynn/subintegrity.html#secret
where every unique security domain has requiremetns about unique
shared-secrets for every unique environment (avoiding cross-security
domain contamination ... like betweeen local garage ISP and your
online banking or employee access).
the issue with real hardware tokens & shared-secrets is that the
concept of perpetuating a unique hardware token per environment
occurs.
I once went around a smartcard show and commented to people in the
booths that if the current smartcard approach (institutional-centric
with unique cards to every individual by every institution) ever
became succesful ... it might be a return to the mid-80s
copy-protection scheme of requiring a unique floppy disk inserted in
the floppy drive for every application (the prospect of being faced
with scores of cards).
the public/private key issue with hardware tokens has a number of
issues:
- the same public key can be registered in different security domains
... and it is not possible for individuals in one security domain,
knowing your public key ... from impersonating you in a different
security domain. this is somewhat a common form of identity theft
where there is heavy reliance of the same (shared) secrets used
in lots of different places.
- succesful uptake of institutional-centric token paradigm could lead
to individuals requiring scores of institutional specific tokens
a hardware token with a public/private key implementation (which is
totally orthogonal to the issue of whether the paradigm has certificates
or totally certificate-less operation) can
- hardware token represents something you have authentication
- relying party having some certified evidence of hardware token
requiring a PIN to operate, can assume that there has been
"something yoi know" authentication (without the relying party
needing to know what the actual PIN is ... so it can be secret
based w/o it having to be shared-secret based)
- registration of the public key and being able to validate the
digital signature ... can imply that there has been something you
have as well as something you know authentication (as long as the
relying party as certified evidence as to the operational
characteristics of the hardware token).
with respect to SSH and public key authentication ... the same
protocol can work whether
• the private key is software-based (and the relying party can only
assume non-shared-secret, but secret pin-based, something you know
authentication by validating a digital signature) or
• two-factor authentication and the private key is hardware token
based.
the public/private key protocol part of ssh can address exploit issues
like things related to shared-secret vis-a-vis non-shared-secret and
evesdroping and replay attacks. what the protocol doesn't tell the
relying party is what does the validation of the digital signature
with the public key actually imply with regard to 3-factor
authentication issues.
the trust and assurance that a relying party can place in the
validation of a digital signature ... requires the relying party
having some knowledge of the environment that originated the digital
signature.
just validating a digital signature with a public key, by itself,
doesn't establish whether it represents one-factor, two-factor or
possibly even three-factor authentication and/or what of the
factors
• something you have
• something you know
• something you are
might be involved.
so i'm wondering if i can have a single individual-centric smartkey
someday ... where the same smartkey will let me open all possible
doors that i might need to open (vehicle, home, office), use my pc,
perform electronic commerce transactions, etc, ... and possibly even
ssh?
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Systems software versus applications software definitions
Newsgroups: comp.software-eng,comp.lang.c,comp.programming,alt.os.development,comp.arch,alt.folklore.computers
Date: Sun, 05 Dec 2004 13:57:41 -0700
ref:
http://www.garlic.com/~lynn/2004p.html#63
http://www.garlic.com/~lynn/2004p.html#64
another dimension of assurance is this stuff:
http://www.software.org/quagmire/
something like 2167a can increase the straight-forward application
development costs by a factor of ten times ... and frequently this
sort of stuff can't be retrofitted after the fact (has to be done up
front before coding ever starts)
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: [Lit.] Buffer overruns
Newsgroups: sci.crypt
Date: Tue, 07 Dec 2004 20:32:10 -0700
"Douglas A. Gwyn" writes:
Programmer oversights are possible in any PL. While bounds
enforcement would prevent *some* attacks, it cannot stop
them all. For example, the program might use a fixed-length
array to implement a ring buffer, and there could be a bug
that surfaces only when the buffer is full, which might not
happen in normal use.
There is an additional danger, in that some programmers would
become even more careless if they believe that the PL will
catch all such mistakes.
the claim is that there is something like a hundred fold increase in
buffer-overflows because of the semantics of string library in C
... compared to other infrastructures. That doesn't mean that it isn't
impossible to do length related errors in other infrastructures ...
it is just the frequency is significantly less often.
as of approx. 1999, the majority of (programming exploits) were
C-related buffer overflows.
as of approx. two years ago ... the exploits were something like
1/3rd c-related buffer overlows
1/3rd automatic scripting
1/3rd social engineering
(not so much that the c-related buffer overflows declined ... but that
the other exploits increased significantly).
there is the multics security review paper .... which cliams that
multics had no known cases of length related exploits. part of this is
the different length related semantics in its implementation language
PLI; PLI implementation typically had buffers with max & current
lengths in a header field. copy/move/io library routines honored the
explicit lengths. It wasn't impossible to write bad code with
length-related problems ... but you had to work much, much harder at
doing it (than is typical in c).
this isn't a situation of PLI catching mistakes ... it is that c
library semantics provide more opportunities to make mistakes compared
to other languages where the semantics make it much less likely to
make mistakes.
past reference to the multics review
http://www.garlic.com/~lynn/2002l.html#42 Thirty Years Later: Lessons from the Multics Security Evaluation
http://www.garlic.com/~lynn/2002l.html#45 Thirty Years Later: Lessons from the Multics Security Evaluation
lots of past posts discussing buffer overflows
http://www.garlic.com/~lynn/subintegrity.html#overflow
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: [Lit.] Buffer overruns
Newsgroups: sci.crypt
Date: Wed, 08 Dec 2004 10:46:06 -0700
"Douglas A. Gwyn" writes:
Anybody can make a nonsensical claim; that doesn't make it true.
The string library isn't even used in buffer management.
there can be two totally different issues here ... buffer
overruns/overflows typically have to do with length management and
moving things into (or out of) buffers. various string libraries do
move things into buffers.
another kind of buffer overrun not mentioned (as frequently) is
incoming characters from some hardware device ... where the rate of
the incoming characters exceed the capacity of the system to allocate
space for them. this buffer overrun/overflow situation usually results
in dropped data ... as opposed to move/copy of data past the end of an
allocated buffer. this kind of buffer overrun strays into the area of
windowing algorithms and rate-based pacing
another buffer management problem can be allocation/deallocation of
the buffers. this is frequently an infrastructure serialization
problem ... with things like dangling pointers still being in use
after dynamic buffer had been de-allocated (or serialization process
trying to play and safe and creating zombie process type problems
trying to make sure a process doesn't go away since there might be
some orphan activity left around which wakes up in the future and
crashes the kernel).
long ago and far away when i was doing kernel stuff ... i got to
release the resource manager
http://www.garlic.com/~lynn/subtopic.html#fairshare
as part of that, developed some sophisticated testing and benchmarking
tools. besides using the benchmarking to validate extremely fine-grain
deterministic scheduling for the fair share scheduler ... i also used
it for severe stress testing ... which, when i started was guarenteed
to crash the kernel. before the release of the resource manager ... i
redesigned and rewrote the kernel serialization infrastructure
eliminating all known cases of kernel crashes because of
dangling/orphan buffer pointers as well as all cases of zombie/hung
process.
I then went on to do a automated kernel problem/crash analysis and
determination tool ... which at one time was used by all corporate
PSRs responsible for analysis of customer kernel problems.
http://www.garlic.com/~lynn/subtopic.html#dumprx
as part of doing this tool ... i gathered extensive data on all
customer reported problems.
About the same time, i also got involved with the disk engineering lab
.. responsible for developing new disks ... at the time, they were
operating with stand-alone computers ... because attempting to operate
operating system with engineering disks had a MTBF of 15 minutes.. I
redesigned and rewrote the io subsystem so that disk engineering could
concurrently operate with multiple engineering disks in an operating
system environment w/o system crashes.
http://www.garlic.com/~lynn/subtopic.html#disk
so when my wife and I got around to starting the HA/CMP project ...
we did a detailed vulnerability analysis of the environment ....
http://www.garlic.com/~lynn/subtopic.html#hacmp
one of the conclusions was that there would be a hundred fold increase
in the incidents of buffer length related problems and exploits
... that what we had been familiar with in other environments (because
of the common length handling paradigm in C).
minor topic drift post related to ha/cmp, parallel oracle
http://www.garlic.com/~lynn/95.html#13
and the relationship to ssl and electronic commerce
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3
and recent thread on what is necessary for industrial and business
strength programming and applications
http://www.garlic.com/~lynn/2004p.html#20 Systems software versus applications software definitions
http://www.garlic.com/~lynn/2004p.html#23 Systems software versus applications software definitions
http://www.garlic.com/~lynn/2004p.html#24 Systems software versus applications software definitions
http://www.garlic.com/~lynn/2004p.html#63 Systems software versus applications software definitions
http://www.garlic.com/~lynn/2004p.html#64 Systems software versus applications software definitions
http://www.garlic.com/~lynn/2004q.html#1 Systems software versus applications software definitions
in any case, our resulting experience was that there was, in fact,
something like a hundred fold increase in buffer length related
problems (compared to other environments and paradigms that we were
familiar with, based on some experience having looked in some detail
at customer and other reported operating system failures and problems
and done detail analysis over the years on the causes) ... previous
reference to collected postings on buffer length problems
http://www.garlic.com/~lynn/subintegrity.html#overflow
one specific posting from 1999, referencing a published buffer overflow
study
http://www.garlic.com/~lynn/99.html#219 Study says buffer overflow is most common security bug
I also have done some analysis of the cve vulnerability & exploit
database ... some summary of the analysis
http://www.garlic.com/~lynn/2004j.html#58
from prior posting
http://www.garlic.com/~lynn/2004q.html#2 [Lit.] Buffer overruns
last year, i was on panel discussion with somebody from one of the
anti-virus companies and a somebody heading up fbi cyber forensic
... he presented the 1/3rd, 1/3rd, 1/3rd statistics. you can actually
see our picture buried some place on this page:
http://www.w3w3.com/CSSB.htm
and mention of the air force security audit and evaluation of multics
(from section 2.3 No Buffer Overflows) that there were no buffer
overflows.
random past references to the air force multics security evaluation:
http://www.garlic.com/~lynn/aadsm14.htm#32 An attack on paypal
http://www.garlic.com/~lynn/aadsm15.htm#23 NCipher Takes Hardware Security To Network Level
http://www.garlic.com/~lynn/aadsm16.htm#1 FAQ: e-Signatures and Payments
http://www.garlic.com/~lynn/aadsm16.htm#8 example: secure computing kernel needed
http://www.garlic.com/~lynn/2002l.html#42 Thirty Years Later: Lessons from the Multics Security Evaluation
http://www.garlic.com/~lynn/2002l.html#44 Thirty Years Later: Lessons from the Multics Security Evaluation
http://www.garlic.com/~lynn/2002l.html#45 Thirty Years Later: Lessons from the Multics Security Evaluation
http://www.garlic.com/~lynn/2002m.html#8 Backdoor in AES ?
http://www.garlic.com/~lynn/2002m.html#10 Backdoor in AES ?
http://www.garlic.com/~lynn/2002m.html#58 The next big things that weren't
http://www.garlic.com/~lynn/2002o.html#78 Newsgroup cliques?
http://www.garlic.com/~lynn/2002p.html#6 unix permissions
http://www.garlic.com/~lynn/2003b.html#0 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003i.html#59 grey-haired assembler programmers (Ritchie's C)
http://www.garlic.com/~lynn/2003j.html#4 A Dark Day
http://www.garlic.com/~lynn/2003k.html#3 Ping: Anne & Lynn Wheeler
http://www.garlic.com/~lynn/2003k.html#48 Who said DAT?
http://www.garlic.com/~lynn/2003l.html#19 Secure OS Thoughts
http://www.garlic.com/~lynn/2003m.html#1 Password / access rights check
http://www.garlic.com/~lynn/2003o.html#5 perfomance vs. key size
http://www.garlic.com/~lynn/2004b.html#51 Using Old OS for Security
http://www.garlic.com/~lynn/2004f.html#20 Why does Windows allow Worms?
http://www.garlic.com/~lynn/2004h.html#2 Adventure game (was:PL/? History (was Hercules))
http://www.garlic.com/~lynn/2004j.html#29 Vintage computers are better than modern crap !
http://www.garlic.com/~lynn/2004j.html#41 Vintage computers are better than modern crap !
http://www.garlic.com/~lynn/2004l.html#21 "Perfect" or "Provable" security both crypto and non-crypto?
http://www.garlic.com/~lynn/2004m.html#25 Shipwrecks
http://www.garlic.com/~lynn/2004o.html#20 RISCs too close to hardware?
http://www.garlic.com/~lynn/2004q.html#2 [Lit.] Buffer overruns
some random topic drift regarding the other kind of buffer
overrun/overflow having to do with pacing algorithms:
http://www.garlic.com/~lynn/93.html#28 Log Structured filesystems -- think twice
http://www.garlic.com/~lynn/94.html#22 CP spooling & programming technology
http://www.garlic.com/~lynn/99.html#33 why is there an "@" key?
http://www.garlic.com/~lynn/2000b.html#11 "Mainframe" Usage
http://www.garlic.com/~lynn/2001h.html#44 Wired News :The Grid: The Next-Gen Internet?
http://www.garlic.com/~lynn/2002.html#38 Buffer overflow
http://www.garlic.com/~lynn/2002i.html#45 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002i.html#57 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002k.html#56 Moore law
http://www.garlic.com/~lynn/2002p.html#28 Western Union data communications?
http://www.garlic.com/~lynn/2002p.html#31 Western Union data communications?
http://www.garlic.com/~lynn/2003b.html#44 filesystem structure, was tape format (long post)
http://www.garlic.com/~lynn/2003g.html#54 Rewrite TCP/IP
http://www.garlic.com/~lynn/2003g.html#64 UT200 (CDC RJE) Software for TOPS-10?
http://www.garlic.com/~lynn/2003.html#55 Cluster and I/O Interconnect: Infiniband, PCI-Express, Gibat
http://www.garlic.com/~lynn/2003.html#59 Cluster and I/O Interconnect: Infiniband, PCI-Express, Gibat
http://www.garlic.com/~lynn/2003j.html#1 FAST - Shame On You Caltech!!!
http://www.garlic.com/~lynn/2003j.html#19 tcp time out for idle sessions
http://www.garlic.com/~lynn/2003j.html#46 Fast TCP
http://www.garlic.com/~lynn/2003p.html#15 packetloss bad for sliding window protocol ?
http://www.garlic.com/~lynn/2004f.html#37 Why doesn't Infiniband supports RDMA multicast
http://www.garlic.com/~lynn/2004k.html#8 FAST TCP makes dialup faster than broadband?
http://www.garlic.com/~lynn/2004k.html#12 FAST TCP makes dialup faster than broadband?
http://www.garlic.com/~lynn/2004k.html#13 FAST TCP makes dialup faster than broadband?
http://www.garlic.com/~lynn/2004k.html#16 FAST TCP makes dialup faster than broadband?
http://www.garlic.com/~lynn/2004k.html#29 CDC STAR-100
http://www.garlic.com/~lynn/2004n.html#35 Shipwrecks
http://www.garlic.com/~lynn/2004o.html#62 360 longevity, was RISCs too close to hardware?
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: [Lit.] Buffer overruns
Newsgroups: sci.crypt
Date: Wed, 08 Dec 2004 10:52:26 -0700
"Arnaud Carré" writes:
yep :-) That's why sometimes when someone said "C langage is as
secure as other", you can't really know if the guy is a poor C coder
and have a bad opinion, or if the guy is a C power user and know
that's possible to write solid code in C ( as in assembly langage),
but you have to spend a lot of efforts, wich is not realistic in
real life for real project. That's why there is other langages such
as ADA , etc... I just pointed out that it's theorically "possible"
to get the same level of security with ANY langage, even assembly.
it isn't just the high/low level of the language that helps/aids a
person in making mistakes but also had the length paradigm/semantics
are implemented.
there are a number of operating system examples that use the same
buffer length conventions as mentioned for PLI ... i.e. buffers have
headers with max/current lengths and strings have headers with current
lengths ... and the various string libraries that manipulate buffers
and strings ... honor the header lengths.
the combination of NULL-terminated strings w/o explicit lengths and
the string library implementation that frequently assumes implied
lengths or that the programmer must know what he is doing ... result
in the majority of buffer overrun/overflow problems.
In the past, I dealt extensively with assembler kernal code that used
the same buffer & string conventions as mentioned for PLI ... and the
environment had far lower incidence of buffer overflow/overrun
problems as C-language environment.
misc. past buffer related posts
http://www.garlic.com/~lynn/subintegrity.html#overflow
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: [Lit.] Buffer overruns
Newsgroups: sci.crypt
Date: Wed, 08 Dec 2004 13:59:21 -0700
"Douglas A. Gwyn" writes:
Anybody can make a nonsensical claim; that doesn't make it true.
The string library isn't even used in buffer management.
I apologize for the misunderstanding there was in the original
post
http://www.garlic.com/~lynn/2004q.html#2 {Lit.] Buffer overruns
buffer overruns/overflows with respect to discarding characters
when things are arriving to fast ... and typically involve characters
arriving faster than the software is prepared to handle
buffer overruns/overflows involving buffer length management
issues and common exploits/vulnerabilities ... frequently associated
with the c programming language environment
dangling/orphan pointers involving buffer allocation management
issues and frequently system failures .... or hung/zombie processes
associated with over zeolous attempts to avoid danglin/orphan
pointers:
http://www.garlic.com/~lynn/2004q.html#3 {Lit.] Buffer overruns
I guess that i was hoping that the context of the post would provide
the ability to distrinquish buffer management as being buffer length
management as opposed to buffer allocation managerment.
the issue in the original post and mentioned in the subsequent post
http://www.garlic.com/~lynn/2004q.html#4 {Lit.] Buffer overruns
was default c programming conventions compared to some other
environments. all the PLI language implementations that i'm aware of
have explicit headers with max & current lengths ... and all the
library routines honor and maintain these header fields consistently.
in an environment where buffers don't carry their own explicit
lengths, then it is frequently pushed on to the programmer's
responsbility to perform the administrative-like tasks associated with
buffer length management operation. for infrastructures where the
length is managed as part of the infrastructure ... it is one less
mistake for the programmer to make.
note that infrastructures that maintain such explicit length paradigms
are not just limited to PLI language environment. There are some
number of system infrastructures where the default buffer length
management is with explicit headers ... and all the library rourtines
tend to conform to the system convention ... regardless of the
language ... even low-level assembler and machine languages. For
these environments, when dropping below the library level ... the
recommended coding conventions also explicitly specify managing the
buffer header length fields (if nothing else to maintain compatibility
with the rest of the environment). again, while it is possible to make
coding mistakes in such environments ... length mistakes are
significantly less common (compared to typical c language coding).
there is one other genre not previously mentioned ... the apl/lisp type
environment where the (language&operational) environment manages both
the allocation and the lengths.
long ago and far away apl\360 had real small workstaces (16k-32k
bytes) in real memory. On every allocation, new storage was allocated
from unallocated storage (but previous allocation was not
discarded). when all unallocated storage ran out, garbage collection
was run to reclaim storage not currently in use by assigned variable.
the amount of actual storage touched was proportional to the number
of assignments and the aggregate size of all variables (where it
was possible for the number of assignments to dominate over the
actual aggregate size of all variables).
when the science center ported apl\360 to cms for cms\apl ...
http://www.garlic.com/~lynn/subtopic.html#545tech
it moved it into a (relatively) large virtual memory environment
(1mbyte to 16mbytes ... typically running on 512kbytes to 1mbyte real
machines). the original apl\360 buffer allocation management tended
to touch all available virtual memory pages ... which could cause
severe virtual memory paging characteristics (even for relatively
small programs that otherwise did a large number of assignments).
random past postings, some including apl references:
http://www.garlic.com/~lynn/subtopic.html#hone
so i have an example of a buffer length coding error. Besides
inventing fair share scheduling as an undergraduate (and getting it
deployed in commercial products), i had also done tty/ascii terminal
support which was also shipped in commercial operating system.
Here is tale from somebody that modified the code to support
a non-standard tty/ascii device ... about middle of the page,
referencing the system crashing 27 times in a single day.
http://www.multicians.org/thvv/360-67.html
The way i had remembered what had happened was since tty/ascii
terminal hardware was limited, i had used one-byte arithmatic to
calculate size of incoming data (and all max lengths were well under
255). Somebody at the MIT urban lab(?) had changed their system to
support a non-standard tty/ascii terminal located some place over at
harvard ... which involved changing max. allowed length to something
like 1200. Since the base implementation calculation was using
one-byte arithmatic (0..255) and was not changed ... the length
calculations got messed up.
random other references to the even ...
http://www.garlic.com/~lynn/99.html#44 Internet and/or ARPANET?
http://www.garlic.com/~lynn/99.html#53 Internet and/or ARPANET?
http://www.garlic.com/~lynn/99.html#207 Life-Advancing Work of Timothy Berners-Lee
http://www.garlic.com/~lynn/2000.html#30 Computer of the century
http://www.garlic.com/~lynn/2000b.html#77 write rings
http://www.garlic.com/~lynn/2000f.html#60 360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.)
http://www.garlic.com/~lynn/2000g.html#2 TSS ancient history, was X86 ultimate CISC? designs)
http://www.garlic.com/~lynn/2000g.html#4 virtualizable 360, was TSS ancient history
http://www.garlic.com/~lynn/2001c.html#36 How Commercial-Off-The-Shelf Systems make society vulnerable
http://www.garlic.com/~lynn/2001f.html#78 HMC . . . does anyone out there like it ?
http://www.garlic.com/~lynn/2001g.html#52 Compaq kills Alpha
http://www.garlic.com/~lynn/2001i.html#32 IBM OS Timeline?
http://www.garlic.com/~lynn/2002f.html#38 Playing Cards was Re: looking for information on the IBM
http://www.garlic.com/~lynn/2002i.html#5 DCAS [Was: Re: 'atomic' memops?]
http://www.garlic.com/~lynn/2002l.html#56 10 choices that were critical to the Net's success
http://www.garlic.com/~lynn/2003.html#73 Card Columns
http://www.garlic.com/~lynn/2003g.html#5 Any DEC 340 Display System Doco ?
http://www.garlic.com/~lynn/2003k.html#55 S/360 IPL from 7 track tape
http://www.garlic.com/~lynn/2003p.html#23 1960s images of IBM 360 mainframes
http://www.garlic.com/~lynn/2004j.html#47 Vintage computers are better than modern crap !
http://www.garlic.com/~lynn/2004k.html#43 Vintage computers are better than modern crap !
http://www.garlic.com/~lynn/2004l.html#18 FW: Looking for Disk Calc program/Exec
http://www.garlic.com/~lynn/2004m.html#26 Shipwrecks
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: XML Data Model
Newsgroups: comp.databases.theory
Date: Wed, 08 Dec 2004 15:20:08 -0700
Tom Hester writes:
But, it seems to me that all of this is beside the point. XML is an
interface language, not a data language. There is no data model for
XML because it does not describe data (facts about the real world).
Rather it describes how to pass text between processes.
as previously mentioned it started out as GML ... generalized
markup language ...
http://www.garlic.com/~lynn/subtopic.html#sgml
and the initials GML are actually the three people at the
science center
http://www.garlic.com/~lynn/subtopic.html#545tech
involved inventing in in 1969. They took "G", "M", and "L" ... and
had to come up with something other than the people's last names.
it was part of an infrastructure for document formating .... and
common reference at the time was markup languages to refer to rules
for formating documents.
however, relatively early in the '70s ... GML tags started taking on
the characteristics of attribute tags as opposed to markup tags (with
some indirection where attribute tags where then given markup rules
... as opposed to giving markup rules directly to contents of a
documents).
so a typically attribute tags was ":address." (original gml tag
format, you see the transition to <address> brackets, later in the 70s
with ISO standardization of SGML).
The issue was the original 1969 invention started out as a formating
markup langauge ... but by the early '70s, the tags were in common use
as information descriptors ... independent of the formating of the
information.
... so something like 4th floor, 545 technology sq, cambridge mass then
in XML semantics is formated like
:address.4th floor, 545 Tech. Sq, Cambridge, Mass,
and the semantics becomes
"4th floor, 545 Tech. Sq, Cambrdige, Mass" IsA "address".
So, the analogy in typical RDBMS, is possibly the data dictionary
giving the field/column characteristic.
The ML-genre allows for hierarchy of constructs ... so there can be
a large file where the whole thing might be a <document> and their
are individual fields that are subsections of <document> ... like
<address> ... where there is a relationship between a thing that
is a <document> and has a characteristic of <address>.
The RDBMS analogy could be considered a single level hierarchy where
there is a primary field that has relationships to other fields in the
same table.
Lets say you have a RDBMS "document" column as the primary field/key
... in RDBMS ... the contents of the field is some identifier that
might be used to distinquish a specific document from some other
document. In the ML paradigm ... what follows the field <document>
... is the actually document ... as opposed to an identifier for
selecting the document (which you might find in a RDBMS paradigm). In
both ML and RDBMS ... the contents of "address" tends to be the actual
address.
So one might claim that in ML ... the contents of the thing marked by
the tags are the actual things (i.e. the actual document, the actual
address, etc). In RDBMS ... the fields might be something that
represents the actual thing (i.e. a document sequence number that
might be used to finding the document someplace) or it might be the
actual thing (like an address).
So ... lets take an XML document that starts with a tag <document> and
in the hierarchy, it might have other tags <address>, <document serial
number>, etc ... all as sub-items in a document hierarchy.
Map that to RDBMS ... you could have one large table ... with the
primary field being the <document serial number>, and an <address>
field and a (very large) <document contents> field.
One could characterize such a RDBMS table as have a one level
hierarchy ... with a primary field (document serial number) and all
the other fields related to the primary field.
In the ML world, the top of the hierarchy would be the actual document
(contents) and all the other fields would be related to (or are
attributes of) the actual contents.
So one might claim that in a RDBMS world ... the document serial
number is the unique thing ... with everything else as attributes of
(or having relationship to) the document serial number. In the ML
world ... the document could be considered the unique thing ... and
everything else (including the document serial number) are
attributes/characteristics of the document (lower down in the
hierarchy).
some of the confusioin is that the same document might contain both
markup tags and attribute tags aka "<br>" ... is a formating, markup
tag ... while "<address>" is a data schema tag. So ... a "<br>"
embedded in a document isn't likely to be considered as part of the
data schema of a document ... while "<address>" may in fact be
considered part of the document data schema.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: [Lit.] Buffer overruns
Newsgroups: sci.crypt
Date: Wed, 08 Dec 2004 15:32:51 -0700
"karl malbrain" writes:
But you are responsible for your own "C-language environment" and
your own discipline. It's very easy in C to add an object to a
character pointer that enables "buffer management" for non-constant
character arrays.
the issue isn't about what might be capable of using C-language
... anymore than what might be capable of using assembler language.
In theory both C and assembler have enuf low-level constructs to
implement almost any paradigm.
the comment was that the standard C-language environment doesn't (as a
default), carry explicit length fields for all strings and buffers
... and that the standard c-language library routines don't (by
default) check the maximum length in the header of a buffer target
... and make sure that it doesn't move more data than is allowed by
what is specified in the buffer header (and therefor overflow the
buffer).
The issue was that all of the PLI language implementations (that i'm
aware of) implemented buffers with length headers and the library
routines all made sure that they didn't violate the buffer lengths
(aka an explicit attribute of a buffer ... in the header of the buffer
... is the maximum length of that buffer). While it is not impossible
to violate the buffer length ... it is much hardere to accidentially
violate buffer lengths compared to the standard C-language
environemnt.
Futhermore, there are a number of systems where the default system
infrastructure (regardless of the language used) have paradigm that
implements buffer lengths in header fields ... and that all languages
and library routines that exist in that system environment tend to
have coding conventions that consistently use and maintain such buffer
header length fields. Again, it isn't impossibly to write assembler
code in such environments that violate buffer lengths ... but since
the default system coding conventions and operations observes the
buffer header length fields ... it tends to be a significantly lower
frequency mistake than occurs in most typical c-language environments
(where it isn't common to find all coding conventions and all library
routines that involve buffers ... implementing, maintaining, and
consistently observing buffer lengths specified in buffer header
fields).
past pieces of this thread
http://www.garlic.com/~lynn/2004q.html#2 [Lib.] Buffer overruns
http://www.garlic.com/~lynn/2004q.html#3 [Lib.] Buffer overruns
http://www.garlic.com/~lynn/2004q.html#4 [Lib.] Buffer overruns
http://www.garlic.com/~lynn/2004q.html#5 [Lib.] Buffer overruns
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: [Lit.] Buffer overruns
Newsgroups: sci.crypt
Date: Wed, 08 Dec 2004 16:07:27 -0700
i've heard various stories about the null terminating by unix (say
compared to multics pli and buffer headers with lengths that were
common at the time).
one was a minimum string header tended to be two bytes (two byte fixed
length) or possibly four bytes (variable length buffer, two byte max
length, two byte current buffer contents length). Having null
termination saved one byte (compared to two byte length header on
fixed string) and saved three bytes compared by keeping track of every
buffers maximum length (aka do nothing and push it up to the
programmer and hopes he does it correctly).
this is the sort of thing from the period of saving every byte
possible in constrained real storage and resource limited
environment. This type of approach also contributed heavily to the y2k
problem ... where years were only implemented as two digit numbers
(there was actually scenario in the past where there one digit years
and problems showed up on decade roll-over ... there was situation
from rolling from the 60s to the 70s).
The other scenario is the addresses/pointers in a string processing
loop becomes a little more expensive. With null-termination ... you
pick up the start of the string and keep processing bytes until you
find a null characters (and only need the pointer to the current
character). In the byte-header scenario ... you have to have both the
current character address and the last character address (and loop
compares whether it has moved past the last character address). It can
also be done with a current character pointer and counter of remaining
characters to process (in either case, the generated machine language
tends to require an additional register).
The startup tends to be slightly more expensive ... say when copying
data or even appending data. If this is a string library appending
data to a buffer ... it has to pick up the source length from the
source string header, it has to pick up the length of the current
destination buffer contents (from the destination buffer header) and
the destination buffer maximum length (from the destination buffer
header). The append library routine then has to have an api semantics
giving either the number of characters actually appended ... or the
inverse ... the number of characters that it was unable to append.
If the api semantics is purely defined as returning characters not
copied/appended ... then the calling code has to
- specify the origin buffer (the origin string length is an attribute
of the origin buffer, kept in the origin buffer header),
- specify the destination buffer (the current string length in the
destiniation buffer is an attribute of the destination buffer, kept in
the destination buffer header, and the maximum length of the
destination buffer is an attribute of the destination buffer, kept in
the destination buffer header).
- call the library append routine,
- check for non-zero return (which would indicate some characters not
copied/appended).
So, if i'm using a standard C-programming library routine to append
one string to another ... what is the fail-safe programming required?
- What is the maximum length of the destination buffer?
- What is the current length of a string in the destination buffer?
- What is the current length of the origin string (to be appended)?
- How do i know whether all of the origin string was appended or only
part of it?
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: [Lit.] Buffer overruns
Newsgroups: sci.crypt
Date: Wed, 08 Dec 2004 16:21:46 -0700
"karl malbrain" writes:
typedef struct {
int len, max;
char *array;
} String;
that wasn't the issue ... in theory, i could be faced with the same
scenario in many common assembler language implementations. however,
many of the standard system infrastructures actually implemented
buffer headers as part of the default system infrastructure
... regardless of the language used in that infrastructure.
the tendancy at the time of multics pli ... and some number of other
operating systems of the era ... was more like a 16bit max, a 16bit
length followed by the actual data (predating unix and c). You got a
pointer to the actual data ... and could backup two bytes to get the
length of the current data ... or backup two more bytes and get the
maximum length of the buffer.
There were some fixed length constant strings that were only used as
source (and never destination) ... and so you only needed the actual
length (and the implementation didn't have to waste the maximum buffer
length ... because it was a constant string the current and maximum
were known to be the same).
Variable length strings/buffers had a four byte header. You got a
pointer to the buffer/string ... and could backup two bytes and get
the length of the current string or back up two more bytes and get the
maximum length of the buffer.
the four byte headers were frequently the default infrastructure
implementation for allocated and variable length buffers (two byte
maximum length followed by two byte current length). You had to go to
a different type to get larger lengths.
lots of standard libraries and infrastructures have supported this
paradigm before either unix or c were created.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: [Lit.] Buffer overruns
Newsgroups: sci.crypt
Date: Wed, 08 Dec 2004 16:39:01 -0700
"karl malbrain" writes:
Guess what? You get to implement your own library in C. I'm
responsible for a 130K lines of code Windows/unix application engine
and we don't even link with libc. The standard c library is of no
interest to us.
so that gets back to my comment about having done detailed vulnerability
and exploit investigation when we started ha/cmp
http://www.garlic.com/~lynn/subtopic.html#hacmp
and predicted that the standard environment would have something like
two orders of magnitude increase in buffer related problems that what
we were used to.
part of ha/cmp was writting a core of code to manage assurance,
availability, fall-over ... and to also provide high performance
distributed lock manager. An objective was to be able to run on a
standard platform and be able to offer fall-over services to a variety
of applications, including off-the-shelf applications that might run
on such platforms. As a result we didn't have control over all the
code that might run on the machine ... either at the point in time
when the code was originally shipped ... or possibly 10-15 years later
when the customer might install any arbitrary application in the
environment.
a big part of the detailed vulnerability and exploit investigation was
to identify possible failure-modes over which we had little or no
control. it identified things that we had to tightly control in our
own code implementation ... but also identified vulnerability/exploits
possibilities where there was going to be little, if any control.
for instance in this scenario ...
http://www.garlic.com/~lynn/95.html#13
we weren't going to be able to control every line of database code.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: [Lit.] Buffer overruns
Newsgroups: sci.crypt
Date: Wed, 08 Dec 2004 16:46:59 -0700
"karl malbrain" writes:
I think you're reading way to much into the idea of "standard library."
is this "standard library" ... as in common use by the large portion
of people writing C code ... or possibly other hypothetical "standard
library" ... like in the pli/multics scnario ... and some other system
infrastructures that predate unix & c?
in the pli/multics scenario ... if all of the kernel is implemented in
pli and all of the kernel uses the pli header strings convention for
both internal kernel constructs as well as constructs that cross the
kernel/application api boundary ... if the standard kernel libraries
all support/assume the standard kernel construct, if all the system
libraries supplied for application support/assume the same standard
header construct .... then this is one form of standard library.
another form of standard library ... is what is the default use by the
largest number of programmers in the c language environment? ... and
possibly a main source of reported buffer length exploits and
vulnerabilities.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: [Lit.] Buffer overruns
Newsgroups: sci.crypt
Date: 09 Dec 2004 00:48:55 -0700
"Douglas A. Gwyn" writes:
There is also an important point that this whole
line of discussion keeps missing, namely: if the
programmer's assumptions are violated at run time,
something *unplanned* is going to happen, which is
bad from the security perspective. That is as true
with boundary-enforced buffer mechanisms as it is
for the sloppy UCB undergraduate hacks that so many
systems "borrowed" for their IP suite. At the very
least, you have a DoS vulnerabililty, but it could
be a lot worse -- since the program will execute
some "error" code that the programmer did not mean
to be executed. Imagine a medical control device
or an automotive or flight control device that
traps to a stack-trace abort when a boundary is
violated.
my statements weren't intended to reflect theoritical conditions
... my statements were intended to reflect that there has been a
signficant difference in the actual observed occurances of buffer
related vulnerabilities/exploits in implementations done with standard
C language as compared to implementations done using buffer header
paradigm.
the assertion is that programmers make signficantly fewer buffer
length abuses/mistakes in environments where there are explicit buffer
length headers ... compared to the frequency of buffer length
abuses/mistakes using standard C language environments.
It is more than a theoritical mistake/abuse/vulnerability/exploit. It
is like if you were getting 1000 fatalities per million miles driven
in one specific kind of vehical ... and 10 fatalities per million
miles driven in another specific kind of vehical ... that it might be
worth consider changing vehicles. This is dispite somebody observing
that it was possible for either vohicle to still go off a mountain
road and kill everybody.
Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: [Lit.] Buffer overruns
Newsgroups: sci.crypt
Date: 09 Dec 2004 00:14:33 -0700
"Douglas A. Gwyn" writes:
The Y2K problems were entirely unrelated to whether
terminated strings were used. In fact with self-
delimiting strings there is less inclination for
the programmer to allocate a fixed-width field.
I never intended to imply that Y2K issues were related in any way to
null terminated strings. The example I heard was that null terminated
strings conserved some bytes compared to the explicit header length
paradigm ... and that Y2k issues arose from similar issues regarding
conserving bytes.
Using null terminated string might save 1-3 bytes compared to an
explicit length implementation .... using two (or one) digit for year
could conserv 2(-3) bytes compared to an implementation using 4 digits
for years.
In the 60s and at least early 70s, there was a lot more effort to
do implementations that conserved bytes ... potentially at the
expensve of something else
the original statement from
http://www.garlic.com/~lynn/2004q.html#8
wasn't intended to claim that all things might use null terminated
string ... but that null terminated string was (possibly) justified
because it used less storage (conserved 1-3 bytes possibly compared to
explicit buffer header ... where the length of the buffer is now
carried as an explicit attribute of the buffer) ... and that many of
the Y2k problems arose from efforts in the same era attempting to also
conserve real storage.
the statements had more to do with trade-offs made in one era with
conserving/optimizing some resource ... and could have significant
later repercusions. I would claim that the a lot of the efforts in the
60s to use two-byte year fields (rather than 4byte) were done to
conserve storage ... and that optimization led to many of the y2k
problems.
I would by analogy argue that the performance/conservation trade-off
of using null terminated strings (based on trade-off choice that it
used less storage than explicit length headers) contributes to the
signficant difference in the number of buffer length vulnerabilities
found in standard c language coding ... compared to the
number/frequency of buffer length vulnerabilities found in
infrastructures that utilize buffer headers with explicit length as
standard coding convention
Again, the statement isn't about what the buffer length fail-safe way
would be to write c language code ... but whether comparing two
default, coding conventions ... one pervasive C coding conventions and
say PLI coding conventions (with explicit lengths attributes carried
with buffers) and the sigificant difference in the number of buffer
length problems ... could the diffence between explicit buffer length
convention compared to the null-termination convention account for
most of the difference
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: [Lit.] Buffer overruns
Newsgroups: sci.crypt
Date: 08 Dec 2004 23:54:06 -0700
"Douglas A. Gwyn" writes:
That is what I (and Karl M in an associated thread)
was referring to, and you're wrong about it. Buffer
length can be managed perfectly well using C, and if
it isn't, blame the programmer for not doing his job.
It isn't C's job to impose assumptions about your
application upon you; if you try to use it to do
harmful things, then harmful things will occur, much
like using a sharp knife (which expert knife users
natually much prefer over safety-enforced knives).
which is my question from
http://www.garlic.com/~lynn/2004q.html#8
given either copy from source to destination buffer ... or append source
to destination buffer ... the buffer header paradigm has the programmer
specifying
- the source string/buffer ... where the source length is an attribute
of the source string/buffer in the header field
- the destination buffer ... where the destination buffer currently
occupied length (in the case of append) is an attribute of the destination
buffer and the maximum buffer length is an attribute of the destination
buffer
- call the library append/copy/move routine
- check for non-zero return (which would indicate some characters
not copied/appended).
the observation is that
- some number of systems and languages prior to creation of unix & c
implemented such paradigms ...
- some of these implementations continue to exist today
- these implementations have tended to have two orders magnitude
fewer of the common buffer overflow vulnerabilities/exploits seen
when using C language implementations.
the prediction was that because of the common C language programming
conventions ... that C language inplemented infrastuctures would tend
to have two orders greater buffer length related problems.
there was no claim that c language couldn't be used to implement
buffer length safe implementations ... the claim was that buffer
unsafe implementations were so much easier in C ... that it would
contribute to a significant increase in buffer length related
vulnerabilities/exploits.
I'm only observing that the air force pli/multics security study claimed
that there were no buffer length related problems .... while there are
significant number of buffer length related problems in C implementations.
My contention was that default/standard C programming conventiosn
contribute to this significant number of buffer length related
problems and by comparison there are other infrastructures with
default/standard probramming conventions with signifantly lower buffer
length related problems.
furthermore the default/standard library and programming conventions
can be independent of the programming language ... where at least
some environments have default/standard library and programming conventions
the same for assembler, pli, and a number of other languages
(being more a characteristic of the infrastructure rather than any
specific language).
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: [Lit.] Buffer overruns
Newsgroups: sci.crypt
Date: Thu, 09 Dec 2004 10:36:43 -0700
"Arnaud Carré" writes:
Agree, that's why I said in previous post that C is (to my opinion)
a low level langage ( but I really love C !). To me, it's a
universal macro-assembler without registers contrainst. You have to
take care of everything but the code generation. ( as with a macro
assembler !)
some of this is coding conventions ... and regardless of whether or
not you can violate rules if you need to.
the claim is that null terminated convention is open to larger number
of programmer mistakes (as opposed to purposeful abuses) compared to
buffer/string explicit lengths (both current length and maximum buffer
length).
i claim that there are infrastructures implemented in assembler (at a
lower level than C) where there are significant fewer buffer overruns
... not because of the language characteristics but because of the
standard infrastructure environment and coding conventions.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: [Announce] The Vintage Computer Forum
Newsgroups: alt.folklore.computers
Date: Thu, 09 Dec 2004 11:04:36 -0700
Morten Reistad writes:
We will see a huge worldwide battle between the internet charging
model and the phone charging model the next decade.
The phone companies want to charge by the bits transported end to
end; the Internet model wants to charge for capacity available. Both
have their merits.
The Internet model is much simpler, and works wonders when things
are growing by leaps and bounds. The Internet still does; despite
some setbacks in the US lately. The "Phone model" works well in a
static world where capacity is scarce.
Mobile phones have taken off in "phone company" mode. They use the
scarseness of the radio spectrum as a proxy to push high
by-the-minute rates. They are currently printing money with their
mobile networks.
there have been claims that the ISO OSI standard was driven by
point-to-point copper-wire people from the telcos and it was only a
little over 10 years ago that the federal gov and numerous
gov. agencies were mandating the elimination of the internet and
converting everything to OSI ... which lacked any internetworking
concept at all.
misc. past comments on osi, gov. mandating eliminating the internet,
etc.
http://www.garlic.com/~lynn/subnetwork.html#xtphsp
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: [Lit.] Buffer overruns
Newsgroups: sci.crypt
Date: Thu, 09 Dec 2004 13:50:05 -0700
Bryan Olson writes:
I saw a PBS documentary on automotive safety in which they explained
that in the early days of the industry, cars were far more dangerous
but people didn't think much about making them safer. The root
cause of the vast majority of the casualties was "driver error".
Blame the drivers, not the machines.
I had to laugh, realizing that the thinking in my own profession is
the better part of a century behind the auto industry. What kind of
engineer would knowingly select a design where common human errors
can easily slip by, and such slips frequently cause disaster?
i've periodically used the analogy to after-market seatbelts
... everybody could install their own seatbelts if they needed ... so
why was it necessary to have manufactures put seatbelts in cars ... or
school buses, or a variety of other vehicles.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: PR/SM Dynamic Time Slice calculation
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Fri, 10 Dec 2004 09:45:46 -0700
gdieh@ibm-main.lst (Diehl, Gary , MVSSupport) writes:
Would someone please enlighten me as to exactly what the PR/SM
calculation for dynamic time slice is?
I see that the "default", as listed in the IRD Redbook under the "How
WLM LPAR CPU Management works" section, clearly states that the time
slice for an LPAR's LP is between 12.5 and 25 ms, and is determined by
the following calculation:
(25ms * # of Physical CPs) / (total # of logical CPs not in stopped
state)
This seems fairly easy... If I have a 1C7 with two LPARS that have 6 and
4 LPs online respectively, then my total LP to CP ratio is 10/7, and my
default time slice is (25 * 7) / 10 = 17.5 ms. So if I cut it down
some, taking one LP off each LPAR, changing the ratio to 8/7, the
default time slice becomes 21.875 ms.
That's all well and good for the "default" time slice. But what does
PR/SM do with it after that? It's dynamic, so my assumption is that the
time slice may be constantly changing.
If I change my LPAR weights, say from 600/400 to 550/450, then what does
that do to the time slice?
If one LPAR is maxxing out, and the other is idle, what does that do to
my time slice?
What else can I to do affect the dynamic time slice, other than vary off
and on LPs?
I'd like to be able to tune to this fine point, if necessary (though
I'll agree that for the most part it is unnecessary to plan to this
level of detail).
from long ago and far away ....
the original vm370 code had time-slice table at boot/ipl ... that
basically had machine model number and time-slice ... at boot, it
would do a store cpuid ... look it up in the table ... and set the
time-slice to the corresponding value.
the vm370 code allowed for pre-empting dispatching ... so if an
interrupt came in for a higher priority task ... there would be a task
switch ... even if the current running task's time-slice hadn't
completed. the time-slice was basically a catcher for recalculating
dispatching task priority (allow multiple, concurrent computationally
intensive tasks to all get periodic shots at the processor).
the processor model time-slice adjustment was to approximately let
progress to be about the same per time-slice aka approximately the
same number of instructions ... regardless of the machine model. part
of this was to constrain the dispatching overhead for time-slice
switch ... you knew the pathlength (number of instructions) for the
dispatching process ... you would possibly like the ratio of
dispatching overhead to productive task execution to exceed some level
... while at the same time allowing some reasonable dispatching
control.
so when i released the resource manager
http://www.garlic.com/~lynn/subtopic.html#fairshare
http://www.garlic.com/~lynn/subtopic.html#wsclock
i made a change
eliminated the cpu processor table ... and substituted a short, timed
compute bound loop done at boot/ipl time. the time-slice at boot was
updated based on measured number rather than the processor table. The
problem was that their were some non-linear effects. cache hit ratio
for the loop was nearly 100percent ... so it wasn't representative of
the actual difference in real-world mip rates between non-cache
machines and cache machines. I was hoping for some code that could
work on a wide range of different processors ... and dynamically adapt
to new processors as they came out ... w/o having to constantly update
the boot/ipl processor model table.
later i made some more changes
1) in the dispatcher ... i added some code that used SSM to
temporarily enable for i/o interrupts and then immediately
disable. this was done prior to going to the overhead of selecting and
dispatching a new task. the idea was that if there was a pending
interrupt ... all the dispatching overhead would be superfluous
because the interrupt would immediately happen anyway ... and would
have to repeat the process.
2) monitored the i/o interrupt rate ... and if the i/o interrupt went
past a (a dynamically adjusted) limit ... it switched the dispatching
task execution from enabled for i/o interrupts to disabled for i/o
interrupts. the result would be that when a task was dispatched, it
would continue to execute until either 1) it gave up processing or 2)
reached time-slice end. i/o interrupt would then only occur in the
dispatcher's i/o interrupt "window"
the issue was that asynchronous i/o interrupts had a very disruptive
effect on cache hit ratios. if the i/o interrupt rate passed some high
level ... you were loosing a large amount of your processing power to
cache thrashing. you were better off slightly delaying i/o interrupts
and then going thru interative cycle to drain all queued i/o
interrupts before allowing task to dispatch. the processing of i/o
interrupts tended to be more efficient because you would interative
loop thru the interrupt handler for all pending i/o interrupts
(improved cache hit rate) and then switch to task execution (improved
cache hit rate). while slight delays in taking i/o interrupts might
appear to decrease i/o thruput ... the slight delays of i/o handling
could be more than offset by the improved thruput of the interrupt
handler having a higher cache hit rate (handling multiple interrupts
in sequence). the result could be both a higher aggregate i/o thruput
plus a higher task thruput (because of the improved cache hit ratio).
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Tru64 and the DECSYSTEM 20
Newsgroups: alt.folklore.computers
Date: Fri, 10 Dec 2004 13:16:09 -0700
"Charlie Gibbs" writes:
It was an evolutionary step from the so-called "intelligent terminals"
of the time. The operative word was "terminal" - IBM intended for
these gadgets to act (at least part-time) as terminals to mainframes.
Hence the 3270 emulation, the SysRq key, etc. But personal computers
were a device whose time had come, and the Law of Unintended
Consequences came into effect.
misc past posts regarding terminal emulation subject
http://www.garlic.com/~lynn/subnetwork.html#emulation
one of the claims for the eventual large growth in PC sales was the
business market segment and having combination of some PC-based
software along with terminal emulation ... so businesses for about the
same price and desk footprint as 3270 ... could get both mainframe
connectivity and local computing (same screen and keyboard). I
actually had this discussion/argument with some of the mac developers
before the mac announced.
this however led to entrenced install base towards the late 80s which
inhibited the evolution of paradigms involving PC operation in
multi-tier mainframe/legacy business environments. misc. 3-tier & saa
posts
http://www.garlic.com/~lynn/subnetwork.html#3tier
one of the complaints of the disk division from the period ... was
that w/o newer and better paradigms for letting distributed computers
access legacy business data ... the legacy business data was going to
leak out of the glass house (significantly cutting glass house disk
growth and fueling demand for the new generations of commodity disks).
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Systems software versus applications software definitions
Newsgroups: comp.software-eng,comp.lang.c,comp.programming,alt.os.development,comp.arch,alt.folklore.comupters
Date: Fri, 10 Dec 2004 13:35:28 -0700
Joona I Palaste writes:
You're much more learned than I am, then. The only thing almost a
decade of writing toy machine language programs to see what the
Commodore 64 can do has taught me in this regard is being able to
convert any integer from 0 to 255 from decimal to hexadecimal or
back in my head in a couple of seconds. Well, it amazed my little
brother for a couple of minutes.
besides learning to read hex from mainframe dumps ... i also learned
to read it from the front console lights as well as the punch holes in
cards (output of assembler and compiler binary/txt decks) ... both
hex->instructions/addresses and hex->character (or in the case of
hex punch cards, holes->hex->instructions/addresses and
holes->hex->ebcdic).
In the past I had made (the mistake of?) posts about the TSM lineage
from a file backup/archive program
http://www.garlic.com/~lynn/subtopic.html#backup
that I had written for internal use that then went thru 3-4 (internal)
releases, eventually packaged as customer product called workstation
datasave facility, and then its morphing into ADSM and now TSM (tivoli
storage manager).
so a couple days ago ... i get email from somebody trying to decode a
TSM tape; included was hex dump of the first 1536 bytes off the tape
... asking me to tell them what TSM had on the tape.
well way back in the dark ages ... you could choose your physical tape
block size ... and the "standard label" tape convention started with
three 80-byte records; vol1, hdr1, hdr2.
so the first 1536 bytes was three 512byte records ... and i recognize
the first 80 bytes of each (512byte) record as starting vol1, hdr1,
hdr2.
the hex dump had included the hex->character translation ... but for
ascii ... and of course the tsm heritage is from ebcdic mainframe
... not ascii (aka it was the ebcdic hex for vol1, hdr1, hdr2) It
didn't even get to the TSM part of the tape data ... it was still all
the os standard label convention.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Tru64 and the DECSYSTEM 20
Newsgroups: alt.folklore.computers
Date: Fri, 10 Dec 2004 14:34:55 -0700
some apple trivia dift ...
my brother was regional apple marketing rep ... he would periodically
come into town and i sometimes got to tag along on apple business
dinners. he said that he had the largest (physical/sq. miles) apple
marketing region in continental us. he also had technical background
and said that he was possibly the only apple marketing rep that knew
how to really take apart and put back together an apple-ii. he
believed he was one of only very few apple marketing reps that also
knew how to setup apple-ii to dial-up the business computer at apple
hdqtrs and directly get the production and delivery schedules.
so in much of the 80s ... what was the business computer in apple
hdqtrs?
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Tru64 and the DECSYSTEM 20
Newsgroups: alt.folklore.computers
Date: Sat, 11 Dec 2004 08:55:25 -0700
Anne & Lynn Wheeler writes:
so in much of the 80s ... what was the business computer in apple
hdqtrs?
hint: the descendent of this business computer and the current
generation apples use the same kind of processor chip.
the folklore is that some number of afficionados of the cancelled
FS project
http://www.garlic.com/~lynn/subtopic.html#futuresys
went off to rochester to build it.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 1GB Tables as Classes, or Tables as Types, and all that
refuted
Newsgroups: comp.databases.theory
Date: Sat, 11 Dec 2004 09:13:51 -0700
"Dawn M. Wolthuis" writes:
Name one precise problem that the hierarchical DBMS's had that is
now present for anyone using an XML model of data. It's time to
drop the flawed notion that data graphs have some inherent problems.
One can build terrible database management systems based on graphs
or good ones. The model, itself, is useful and never was abandoned
in reality (or in Reality, a database from the company Northgate --
McDonnell-Douglas and variants of the company kept this graph-based
solution active since the early 70's as the Microdata company, and
it is still being sold and used today)
Graph-based data models have survived the Relational Database trend and will
now get a new push given that more people now understand -- and even more
will! -- that RDBMS's have no better theorectical basis than graph-based
database management tools. And, PA-LEASE STOP calling them "Network" and
"Hierarchical" -- they are graphs and trees. No other niche in the computer
industry has problems using mathematical terms "graphs" and "trees". Using
a mathematical term ("relations") for your preferred data model, while
avoiding the mathematical terms for the others is way too obvious a form of
spin and, by golly, it worked for a couple of decades, dag nab it (thus
holding back our industry unnecessarily, methinks), but the time has come to
AT LEAST get away from the N & H terms. --dawn
note that the arguments that i remember going on between stl/bldg.90
and sjr/bldg.28 wasn't so much about the information structure. the
hierarchical and network databases of the 60s used physical pointers
and system/r (first rdbms)
http://www.garlic.com/~lynn/subtopic.html#systemr
used indexes.
the argument was the trade-off between the human advministrative
effort to maintain the physical pointers (which was subsumed in large
part by system/r indexes) and the indexes typically doubling the
physical disk spaced occupied by the database (because of the indexes)
... as well as the index lookup being slower than direct pointers. The
issue was could you trade-off processing resources and disk space
resources against the manual administrative efforts.
during the 70s and 80s, the manual resources became scarcer and more
expensive while processing and disk space became much more plentiful
and less expensive. also with large and less expensive real memories
of the 80s, it was possible to cache some amount of the indexes,
off-setting some amount of the index processing penalty.
however, physical pointers (used in the 60s) aren't necessarily
intrinsicly a characteristic of the information organization ... just
a characteristic of the resource trade-off implementation
circumstances of the period.
there are still quite a few large, major ims installations still in
existance
http://www-306.ibm.com/software/data/ims/
from above:
IBM's premier transactional and hierarchical database management
system for critical on-line operational and e-business applications
and data, enabling Information Integration, Management, and
Scalability
and
http://search390.techtarget.com/featuredTopic/0,290042,sid10_gci990489,00.html
When most mainframers hear Web-enabling a database, they think
connecting DB2 to the Web. But IMS, IBM's older database, is just as
Web worthy. To hear more about Webifying an IMS database, check out
this Webcast with Jim Keohane.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Tru64 and the DECSYSTEM 20
Newsgroups: alt.folklore.computers
Date: Sat, 11 Dec 2004 09:17:15 -0700
keith writes:
Must be AS/400. Interesting that M$ also used AS/400s to run their
business (until mid 90's perhaps).
originally s/38 ... the as/400 was the s/38 follow-on, as/400
initially built using cisc processor ... but later converted to risc
processor.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Question on internal/external IPs
Newsgroups: comp.security.firewalls
Date: Sat, 11 Dec 2004 16:04:03 -0700
ibuprofin@painkiller.example.tld (Moe Trin) writes:
ftp://ftp.isi.edu/in-notes/rfc-index.txt
[compton ~]$ zgrep -c '^[0123]' rfcs/rfc-index.11.09.04.txt.gz
3931
[compton ~]$ zcat rfcs/rfc-index.11.09.04.txt.gz | tail -3
3956 Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast
Address. P. Savola, B. Haberman. November 2004. (Format: TXT=40136
bytes) (Updates RFC3306) (Status: PROPOSED STANDARD)
[compton ~]$
I imagine there are a few more documents since then, as I only check
it about every 60 days. The index file alone is nearly 15,000 lines
or 635k.
this is my index
http://www.garlic.com/~lynn/rfcietff.htm
at the moment it is up-to-date ... except the two RFCs listed in the
rfc-editor announcement that went out today.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: [Lit.] Buffer overruns
Newsgroups: sci.crypt
Date: Sun, 12 Dec 2004 09:29:22 -0700
Bryan Olson writes:
By the standards of safer programming languages, memcpy is *not*
perfectly well-behaved. It has undefined behavior if the programmer
passes a size_t that is too large.
my experience is that programs written in C, except for buffer length
failures ... tend to have failures & mistake rates similar to other
environments; for instance storage cancers seem to crop up about as
frequently in C environments as in many other environments.
one might then conclude that storage cancers are a relatively common
problem across a large number of different environments (except for
the apl/lisp/etc environments where storage allocation/deallocation
responsibilities have been totally removed from the programmers's
responsibility). given that programmers are going to be given the
allocation/deallocation responsibility ... then it is probably going
to be require some development methodology to address storage cancer
type issues.
the buffer length scenario goes to a completely different level
... since the buffer length failure & mistake rate in significantly
larger in c than lots of other environments (possibly by two orders of
magnitude) ... there is some statement somewhare that given large enuf
quantitative difference ... it can become a qualitative difference.
during much of the 90s ... i was told that it was simply just another
programming development issue and better tools were going to eliminate
the C language environment tendency towards buffer length mistakes.
However, it seems like that the better tools still have had little
effect on the buffer length mistakes ... new C application seems to
have just as many buffer length mistakes as the code from the 80s.
i looked at the structural differences and observed
a) null termination convention appeared to encourage programmers
to believe that length was an attribute of the data pattern
b) default buffer allocation/deallocation in C ... was having buffer
construct being simply default to a C address/pointer construct
... with the responsibility being placed on the programmer for
maintanence of the buffer length attribute. however, one could claim
that the result of the null-convention encouraging programmers to
think of length as an attribute of the data pattern rather than and
attribute of the structure containing the data ... programmers would
frequently forgot to enforce lengths about the length attributes of
buffers (which was their responsibility by the convention of mapping
buffer constructs to simply pointers and leaving programmers to manage
the length attribute).
so, i was aware of numerous infrastructures during the 60s which took
the approach that length was an attribute of the structures ...
rather than the data. a simple example is buffer structures which had
used a pointer convention to the start of the data portion of the
buffer ... but if you backed up two bytes, it had the length of the
data in the buffer ... and if you backed up two more bytes, it had the
(max) length of the buffer (buffers explicitly carried their length
attribute, it was not the responsibility of the programmer to carry it
around in their heads). Furthermore, the length attribute of data
was carriend by the structure that contained that data ... rather than
an attribute implicit in the pattern of the data.
long ago and far away ... when i asked why the null data pattern
methodology was chosen and not the length header convention (common in
the 60s) ... i was told that they specifically chose the C approach
because it saved a couple bytes of storage per structure, an
instruction or two in loops ... and possibly a register.
so i claim that there is an intersection of characteristics ...
somewhat unique to C (as compared to many other environments that have
radically lower frequency of buffer length problems); the null pattern
convention for length ... which encourages programmers to think of
length as an attribute of the pattern of the data (and something that
don't need to explicitly manage) and buffer allocation/deallocation
construct is mapped to simple pointer with implicity requirement that
the programmer is (now manually) responsible for the length attribute
of the buffer constructs. Buffers are real constructs in C
environments with both an pointer attribute and a length attribute ...
however only the pointer attribute is mapped to explicit C language
construct, a pointer ... and the length attribute is carried
implicitly ... forcing programmers to manage it ... and the null
terminating convention is encouraging programmers to think of length
as an attribute of the data pattern ... as opposed to an attribute of
the structures that contain the data.
so switching roles ... i'm an attacker ... i'm looking at typical
environment where C programmers frequently are assuming that length is
an attribute of some pattern in well-behaved data. so it seems that
besides just old-fashion, run-of-the-mill program failures because the
programmer made a mistake ... the bad guys can frequently and
succesfully attack C-language environments by sending ill-behaved
data.
that makes common c-language implemented environments ... not only
subject to failures because of large increase in buffer related
programmer mistakes (compared to other environments) .... but these
failure characteristics also represent explicit attack
vulnerabilities.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 1GB Tables as Classes, or Tables as Types, and all that
refuted
Newsgroups: comp.databases.theory
Date: Mon, 13 Dec 2004 10:13:33 -0700
alfredo_novoa@hotmail.com (Alfredo Novoa) writes:
The DBMS approach was one of the biggest advances in the computer
field, but most programmers are not aware of that.
old time databases from batch processing days tended to be services to
manage complex data ... more complex than reading/writing files
sequentially (more complex than the original tape in & tape out
.... and then sequential paradigm moved to random access disks).
dbms has tended to refer to infrastructures (somewhat associated with
online) that managed concurrent access by multiple different
programs/applications ... providing locking, transaction consistency,
acid properties, etc. ... aka dbms tended to represent concurrency
control for databases.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: [Lit.] Buffer overruns
Newsgroups: sci.crypt
Date: Mon, 13 Dec 2004 09:47:31 -0700
daw@taverner.cs.berkeley.edu (David Wagner) writes:
Part of one reasonable way of coping is to use a safe language where
array bounds are checked, etc., so that some kinds of accidental
slipups are less deadly.
i would claim that it wouldn't even take that much to eliminate
majority of the current c environment buffer length slipups ... just
have buffer constructs carry both their address and its length (to
eliminate the problems with the programmers being required to carry
the length around in their heads .... and/or assuming that its is
represented as part of the data pattern contained in the buffer
construct).
there are environments where the buffer construct carries both the
address and the length ... but don't actually enforce array bounds
checking ... but with the length readily available and most library
routines taking advantage of buffer constructs carrying their own
lengths ... programmers have to work much, much harder to make
mistakes and violate the bounds.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Two Fedora Core 2 problems
Newsgroups: linux.redhat
Date: Mon, 13 Dec 2004 10:03:47 -0700
bushwah writes:
2. No sound. The Soundcard Detection says:
i'm not sure fc3 gets much better ... i just did brand new fc3 install
on new vaio a290 laptop after completely wiping the disk. it has ac97
motherboard chip.
i also recently did upgrade of two machines from fc2 to fc3 ... old
dell precision 410 with motherboard CS chip, and a dell dimension 8300
with (bios) disabled motherboard ac97 chip and a soundblaster card.
all three systems are at the (same) most current fc3 maintenance
hardware detection finds all three chips ... but on the 8300, the
soundblaster doesn't show up in /proc/asound/cards so alsamixer
doesn't recognize it. on the other two machines (vaio and 410), i've
sent alsamixer values to non-mute and maximum volume.
the vaio bios plays a couple notes on startup ... so the hardware
works ... but w/fc3 nothing is heard.
the 410 is dual-boot machine and the sound works fine under windows,
also indicating the hardware works; also during fc3 boot, there are a
couple scratchy poping sounds (so it appears to be trying to do
something).
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: High Level Assembler for MVS & VM & VSE
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Mon, 13 Dec 2004 21:26:41 -0700
bblack@ibm-main.lst (Bruce Black) writes:
Yes. I was recently very surprised to see that it was clearly
documented in POPs that the various flavors or OR, AND and EXCLUSIVE
OR are not serialized for storage access on multi-processors. They
do a fetch and store, and another processor can sneak in between
those. I just assumed for years that this could not happen. Of
course, you all probably know what "assume" does.
CS (compare and swap) is one technique that can be used to
compensate. It is a bit more work to twiddle one bit but if it has
gotta be done, then you do it.
charlie invented compare&swap while working on fine-grain
locking for cp/67 360/67 smp at the science center
http://www.garlic.com/~lynn/subtopic.html#545tech
C-A-S was chosen because they are charlie's initials ... and then we
had to come up with an opcode mneumonic that matched his initials. at
the time, the only atomic instruction was test-and-set.
trying to get the instruction into 370 architecture ... the push back
from architecture (padegs and smith, mostly smith), was that a new
SMP-only instruction couldn't be justified ... and some non-SMP
(single processor) justification had to be supplied for
compare&swap in order to get it into 370 architecture.
that was the origin of the original write-up that was included with
the compare&swap instruction programming notes in the
principle of operations (but since moved to the appendix)
... describing the use of compare&swap for multi-thread
application code ... where the application code might be interrupted
in the middle of some operation and another thread resumed. note that
the immediate-modify instructions do a non-atomic fetch/store
... however interruptions only occur on instruction boundaries (at
least for these instructions) ... so it isn't an issue in a
single-processor environment ... but concurrent operation in a
multiple processor environment can lead to unpredictable results
multiprogramming/multiprocessing appendix from esa/390 pop:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/A.6?SHELF=EZ2HW125&DT=19970613131822&CASE=
from above:
When two or more programs sharing common storage locations are
being executed concurrently in a multiprogramming or
multiprocessing environment, one program may, for example, set a
flag bit in the common-storage area for testing by another program.
It should be noted that the instructions AND (NI or NC), EXCLUSIVE
OR (XI or XC), and OR (OI or OC) could be used to set flag bits in
a multiprogramming environment; but the same instructions may cause
program logic errors in a multiprocessing configuration where two
or more CPUs can fetch, modify, and store data in the same storage
locations simultaneously.
... snip ...
the above appendix reference also contains latest version of the write
ups.
random other compare&swap and/or smp posts:
http://www.garlic.com/~lynn/subtopic.html#smp
a current page for padegs:
http://inventions.lza.lv/eng/izgudrotaji/PadegsA.asp
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Integer types for 128-bit addressing
Newsgroups: comp.arch
Date: Tue, 14 Dec 2004 07:30:23 -0700
nmm1@cus.cam.ac.uk (Nick Maclaren) writes:
The technique is particularly recommended for use in C programs in
conjunction with the numerous transparent garbage collectors claimed
to be available for that language.
some versions of "idea" used the technique in the 80s.
started a little bit after system/r (original rdbms)
http://www.garlic.com/~lynn/subtopic.html#systemr
in bldg28/sjr ... idea was a semantic network database done by the
vlsi tools group in bldg29/lsg.
part of *idea* was an attempt to integrate logical and physical chip
design. the low-level implementation used bidirectional links
emulating content addressable relationships (as opposed to the
physical pointers that characteristic of network databases of the
60s).
i happened to get to work on both.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Amusing acronym
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Tue, 14 Dec 2004 09:09:15 -0700
edjaffe@ibm-main.lst (Edward E. Jaffe) writes:
It's the other way around. IBM came first. Long, long before HAL.
there was a HAL vlsi chip company in the 90s doing a 64bit sparc chip
.... with investment from fujitsu and was eventually taken over by
fujitsu. there was some claim that american started the sjc<->narita
md11 service ... in part, because hal had standing 1st class
reservations on the flight every week.
minor reference:
http://www.garlic.com/~lynn/2004p.html#40 Computers in movies
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Listserv for TCPIP
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Tue, 14 Dec 2004 10:25:44 -0700
eugene.muszak@ibm-main.lst (Gene Muszak) writes:
Can someone please post the link for the listserv for TCPIP.
some history on bitnet
http://www.lsoft.com/products/listserv-history.asp
note that there was a precursor on the internal network
http://www.garlic.com/~lynn/subnetwork.html#internalnet
products from this vendor
http://www.lsoft.com/products/products.asp
another mail list server (written in perl):
http://www.greatcircle.com/majordomo/
so did you want a listserv that supports tcpip ... or a tcpip mailing
list? many of the original bitnet lists are gatewayed to newsgroups in
the bit.listserv hierarchy ... aka a couple tcp mailing lists are
gatewayed as:
bit.listserv.tcpip-l
bit.listserv.ibmtcp-l
tcpip-l seems to be defunct.
pointer to ibmtcp-l mailing list
http://catalist.lsoft.com/scripts/wl.exe?SL1=IBMTCP-L&H=VM.MARIST.EDU
ibmtcp-l archive page:
http://vm.marist.edu/htbin/wlvindex?IBMTCP-L
other lists at marist.edu:
http://catalist.lsoft.com/scripts/wl.exe?XH=VM.MARIST.EDU
the "official" catalog of listserv lists:
http://www.lsoft.com/catalist.html
other archaeological references:
http://nethistory.dumbentia.com/nm8608.html
http://www.ocf.berkeley.edu/Library/Network/listserv.groups
some topic drift: rfc 1044 support for mainframe tcpip (originally
done in vm370 using vs/pascal ... and later ported to mvs with
a thin vm370 emulation layer between tcp and mvs)
http://www.garlic.com/~lynn/subnetwork.html#1044
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: [Lit.] Buffer overruns
Newsgroups: sci.crypt
Date: Tue, 14 Dec 2004 10:49:18 -0700
"karl malbrain" writes:
The levels are separated by PROTOCOL and implemented by LANGUAGE.
The levels themselves are conceptual. Perhaps, see OSI NETWORKING
charts or use definitions.
total random topic drift ... tried to get hsp protocol as a standard
item in x3s3.3 ... however it went directly from transport to lan/mac
layer. Unfortunately ISO had a rule that neither ISO nor ISO chartered
organizations (ANSI) could do networking standardization that violated
OSI model.
x3s3.3 rejected hsp because:
- lan/mac violates OSI ... in part, because the interface sits in
the middle of OSI layer3/networking ... and therefor any protocol
that talks to lan/mac interface violates the OSI model
- going directly from transport to lan/mac ... bypassed the
osi model layer3/layer4 interface and therefor violated the
OSI model
- hsp would support internetworking ... aka IP; internetworking
is non-existant in the OSI model ... and therefor supporting
internetworking violates OSI model.
random refs:
http://www.garlic.com/~lynn/subnetwork.html#xtphsp
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: [Lit.] Buffer overruns
Newsgroups: sci.crypt
Date: Tue, 14 Dec 2004 14:30:55 -0700
ref:
http://www.garlic.com/~lynn/2004q.html#34
when osi comes up ... i frequently claim it should be taught as
something that seems so terribly perfect ... and yet so horribly wrong
... and iso compounded the problem by mandating it couldn't be
changed
http://www.garlic.com/~lynn/subnetwork.html#xtphsp
besides the prediction about the enormous increase in buffer
length problems ... we did uncover some number of other things
crawling thru lots of c-code ... including tahoe/reno tcpip code
for ha/cmp
http://www.garlic.com/~lynn/subtopic.html#hacmp
a simple one was trying to do fall-over and ip-address take-over
(simply) with servers. it turns out that in client/server environment
with tahoe/reno clients ... there was a performance feature of the
tahoe/reno arp code. the ip layer saved the last response from calling
arp-cache code ... and the next time thru ... if the ip-address was
the same ... it used the previous arp-cache response. this value never
timed out. in a heavily client/server oriented environment ... a
client might always use a local gateway ip address and therefor the
client could go for hrs w/o changing the ip address that it was
talking to (and never get around to actually recalling the arp-cache
code ... which had timed-out the mac address hrs earlier).
i had done rfc 1044 support ... random recent reference
http://www.garlic.com/~lynn/2004q.html#33 Listserv for TCPIP
and
http://www.garlic.com/~lynn/subnetwork.html#1044
the base code had been done in vs/pascal ... and could consume a 3090
processor getting about 43kbytes/sec aggregate thruput using an 8232
controller.
i had extended the standard tcpip product with rfc1044 suppoert (also
in vs/pascal) and done some tuning at cray research (on a scheduled
flight to Minneapolis to do some of the work, wheels lifted from sfo
20 minutes late ... and five minutes before the earthquake hit). We
finally got performance up to 1mbyte/sec thruput between a 4341-clone
and a cray ... using only about 20% of the 4341-clone (which was maybe
1/10th the mip rate of a 3090 processor ... aka nearly 25times the
bytes/sec using about 1/50th as much cpu).
vs/pascal had started at bldg.29/lsg vlsi lab ... by P & W. at the
time, bldg.29/lsg was using DeRemer's TWS stuff for a lot of
specialized grammers associated with vlsi design (and other stuff). W
then left to do a 3274-clone startup, then VP of software development
at mips and then general manager at sun of a group that included
JAVA. P stayed around for several years and then left to join DeRemor
at metaware (i was trying to talk P into doing a C-frontend for
vs/pascal ... and i left for a six week lecture tour in europe and
when I got back he was over in santa cruz). I did talk the company
into subcontracting to metaware for a c-compiler ... that is why aos
(bsd port) on the pc/rt was done w/metaware c-compiler.
note however, I know of no buffer length exploit in any of the
vs/pascal implemented stuff ... and it was possible to tune vs/pascal
for pretty high performance (rfc 1044 support as simple example) ...
note however, vs/pascal had a number of significant extensions. I
found this out several years later porting a 60k instruction vs/pascal
application (at the time, ran on both mainframes and rs/6000s) to
another platform. This appeared to be a vanilla pascal implementation
possibly never been used for anything other than student projects
(they had also outsourced their pascal support to some place on the
opposite side of the planet ... which met a lot of delay in turning
around bugs).
totally unrelated recent bldg.29/lsg reference (although it also
involved vs/pascal):
http://www.garlic.com/~lynn/2004q.html#31 Integer types for 128-bit addressing
far away reference to the (really old) tws manual:
http://www.garlic.com/~lynn/2004d.html#71 What terminology reflects the "first" computer language ?
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: CAS and LL/SC
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Tue, 14 Dec 2004 15:44:24 -0700
Eric Smith <eric-no-spam-for-me@brouhaha.com> writes:
Interesting. Other than 360 and derivatives, and some of the Motorola
68K processors (starting with MC68020), what architectures have included
CAS?
Who invented the Load Locked and Store Conditional instructions used
in the MIPS, Power, and Alpha architectures, and where else have they
been used?
original rios/6000 didn't support smp ... so there was no
multiprocessor issues ... but it was a risc architecture with nothing
that did both a load, modify, store in single instrucation (as the
immediate flag bit instructions on 360) ... ao it had a problem with
doing single-processor multi-threading of enabled code ... so a
compare&swap macro was invented ... it did a special supervisor
call which placed you in the supervisor call interrupt handler
disabled for interrupts ... which then had a small amount of fastpath
code to emulate compare&swap semantics and immediately return.
perform locked operation eventually shows up in mainframe
i remember some early somerset hardware architecture meetings
designing perform lock like hardware semantics ... i don't remember
any details of where it originated. a big issue for risc was not
having a single instruction that did possibly more than one thing
... &/or did both load & store. so the lock & store separate
instructions would have tended to be a risc-oriented smp thing. it
would have been unlikely to have originated in the 801 affiliated
groups since they were so zealously anti-smp and anti cache
consistency.
doing a little search engine turns up this discussion (power/pc aka
somerset compared w/ia32):
http://www.usenix.org/events/jvm02/full_papers/alpern/alpern_html/node10.html
this mentions compare&swap for sparc
http://www.syssoft.uni-trier.de/systemsoftware/Download/Fruehere_Veranstaltungen/Seminare/Prozessorarchitekturen/Prozessorarchitekturen-6.html
and off-the-wall mention of compare&swap instruction in
tcp/ip history thread
http://www.postel.org/pipermail/internet-history/2004-September/000431.html
misc. past reference to mainframe perform lock instruction.
http://www.garlic.com/~lynn/98.html#36 What is MVS/ESA?
http://www.garlic.com/~lynn/2001k.html#16 Minimalist design (was Re: Parity - why even or odd)
http://www.garlic.com/~lynn/2002n.html#74 Everything you wanted to know about z900 from IBM
http://www.garlic.com/~lynn/2003j.html#58 atomic memory-operation question
http://www.garlic.com/~lynn/2004b.html#57 PLO instruction
http://www.garlic.com/~lynn/2004d.html#43 [OT] Microsoft aggressive search plans revealed
http://www.garlic.com/~lynn/2004k.html#39 August 23, 1957
http://www.garlic.com/~lynn/2004l.html#55 Access to AMD 64 bit developer centre
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: A Glimpse into PC Development Philosophy
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Tue, 14 Dec 2004 15:59:41 -0700
howard@ibm-main.lst (Howard Brazee) writes:
I worked at a place that had a beta of Amdahl's operating system
Aspen. I liked the OS, but it never made it past beta. In the help
about reading labeled tapes it mentioned that labeled tapes are used
by "a popular water-cooled computer".
part of the issue was that simpson (aka hasp, crabtree, et al) had
done something similar before leaving and joining amdahl ... and so
there were threats of litigation and independent auditors reading
code.
one of the (big) issues with both uts & aix/370 (a port of ucla locus)
running under vm ... was that there was a bunch of mainframe specific
processor and i/o device erep recovery, diagnostic, and recording
support ... which was expensive to duplicate.
I knew people in both the aspen and uts groups and suggested that too
bad they couldn't get together and do a uts layer to aspen ... in much
the same way that bell had done unix to ssup-layer on tss/370. I have
vague memories of there being some differences of opinion between
dallas and sunnyvale.
for random drift, collection of past postings mentioning hasp:
http://www.garlic.com/~lynn/subtopic.html#hasp
past mention of rasp (project before simpson going to dallas/amdahl)
and aspen (project after simpson going to dallas/amdahl):
http://www.garlic.com/~lynn/2000f.html#68 TSS ancient history, was X86 ultimate CISC? designs)
http://www.garlic.com/~lynn/2000f.html#69 TSS ancient history, was X86 ultimate CISC? designs)
http://www.garlic.com/~lynn/2000f.html#70 TSS ancient history, was X86 ultimate CISC? designs)
http://www.garlic.com/~lynn/2001g.html#35 Did AT&T offer Unix to Digital Equipment in the 70s?
http://www.garlic.com/~lynn/2002g.html#0 Blade architectures
http://www.garlic.com/~lynn/2002i.html#63 Hercules and System/390 - do we need it?
past mention of the tss/unix work
http://www.garlic.com/~lynn/96.html#4a John Hartmann's Birthday Party
http://www.garlic.com/~lynn/2000b.html#61 VM (not VMS or Virtual Machine, the IBM sort)
http://www.garlic.com/~lynn/2000c.html#8 IBM Linux
http://www.garlic.com/~lynn/2000f.html#68 TSS ancient history, was X86 ultimate CISC? designs)
http://www.garlic.com/~lynn/2000f.html#70 TSS ancient history, was X86 ultimate CISC? designs)
http://www.garlic.com/~lynn/2000.html#64 distributed locking patents
http://www.garlic.com/~lynn/2000.html#92 Ux's good points.
http://www.garlic.com/~lynn/2001d.html#77 Pentium 4 Prefetch engine?
http://www.garlic.com/~lynn/2001e.html#19 SIMTICS
http://www.garlic.com/~lynn/2001f.html#20 VM-CMS emulator
http://www.garlic.com/~lynn/2001f.html#22 Early AIX including AIX/370
http://www.garlic.com/~lynn/2001f.html#23 MERT Operating System & Microkernels
http://www.garlic.com/~lynn/2001l.html#8 mainframe question
http://www.garlic.com/~lynn/2001l.html#17 mainframe question
http://www.garlic.com/~lynn/2002m.html#21 Original K & R C Compilers
http://www.garlic.com/~lynn/2002m.html#24 Original K & R C Compilers
http://www.garlic.com/~lynn/2003c.html#53 HASP assembly: What the heck is an MVT ABEND 422?
http://www.garlic.com/~lynn/2003d.html#54 Filesystems
http://www.garlic.com/~lynn/2003g.html#24 UltraSPARC-IIIi
http://www.garlic.com/~lynn/2003g.html#31 Lisp Machines
http://www.garlic.com/~lynn/2004g.html#4 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004p.html#10 vm/370 smp support and shared segment protection hack
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: CAS and LL/SC
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Wed, 15 Dec 2004 09:13:28 -0700
Brian Inglis writes:
Could explain some of why the RT disappeared and was replaced by or
evolved into the RS then the SP. Technical workstations without order
of magnitude priced same architecture servers have limited market.
PC/RT (ROMP chip) was originally targeted as replacement for the
displaywriter by OPD (office products division). when the product was
canceled, the group quickly retargeted it for the unix workstation
market.
core displaywriter replacement was built on CPr and written in
PL.8. with retargeting the product to the unix workstation market,
the PL.8 programmers were given the task of writting something called
the VRM ... creating an abstract virtual machine layer ... and
the unix port to the VRM layer was outsourced to the company that
had done the PC/IX port.
after PC/RT was out, the palo alto acis group, which had been working
on a bsd port to 370 ... got retarged to pc/rt ... and they quickly
built "aos" running on the bare metal. recent "aos" references in
thread in sci.crypt:
http://www.garlic.com/~lynn/2004q.html#35 [Lit.] Buffer overruns
in the above, there is discussion of choice of metaware for
370 c-compiler ... but they kept the same compiler when "aos" was
retargeted to pc/rt & ROMP.
random past 801, romp, rios, somerset, etc. posts
http://www.garlic.com/~lynn/subtopic.html#801
and other recent unix-related topic drift:
http://www.garlic.com/~lynn/2004q.html#37 A Glimpse into PC Development Philosphy
aix/370 mentioned in the above ... was done by palo alto acis ...
after the "aos" work ... however ... rather than bsd ... it was
ucla locus. it was sort of unix saa ... random drifts related to
saa
http://www.garlic.com/~lynn/subnetwork.html#3tier
where ucla locus was ported to both aix/370 and aix/ps2 ... supposedly
providing transparent file & process migration across 370 and ps2
boundary.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: CAS and LL/SC
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Wed, 15 Dec 2004 09:13:28 -0700
Brian Inglis writes:
Could explain some of why the RT disappeared and was replaced by or
evolved into the RS then the SP. Technical workstations without order
of magnitude priced same architecture servers have limited market.
PC/RT (ROMP chip) was originally targeted as replacement for the
displaywriter by OPD (office products division). when the product was
canceled, the group quickly retargeted it for the unix workstation
market.
core displaywriter replacement was built on CPr and written in
PL.8. with retargeting the product to the unix workstation market,
the PL.8 programmers were given the task of writting something called
the VRM ... creating an abstract virtual machine layer ... and
the unix port to the VRM layer was outsourced to the company that
had done the PC/IX port.
after PC/RT was out, the palo alto acis group, which had been working
on a bsd port to 370 ... got retarged to pc/rt ... and they quickly
built "aos" running on the bare metal. recent "aos" references in
thread in sci.crypt:
http://www.garlic.com/~lynn/2004q.html#35 [Lit.] Buffer overruns
in the above, there is discussion of choice of metaware for
370 c-compiler ... but they kept the same compiler when "aos" was
retargeted to pc/rt & ROMP.
random past 801, romp, rios, somerset, etc. posts
http://www.garlic.com/~lynn/subtopic.html#801
and other recent unix-related topic drift:
http://www.garlic.com/~lynn/2004q.html#37 A Glimpse into PC Development Philosphy
aix/370 mentioned in the above ... was done by palo alto acis ...
after the "aos" work ... however ... rather than bsd ... it was
ucla locus. it was sort of unix saa ... random drifts related to
saa
http://www.garlic.com/~lynn/subnetwork.html#3tier
where ucla locus was ported to both aix/370 and aix/ps2 ... supposedly
providing transparent file & process migration across 370 and ps2
boundary.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Tru64 and the DECSYSTEM 20
Newsgroups: alt.folklore.computers
Date: Wed, 15 Dec 2004 09:44:31 -0700
mwojcik@newsguy.com (Michael Wojcik) writes:
I don't believe any AS/400 models use PowerPC. They use
POWER-family chips - PowerAS and POWER5, IIRC - but not PowerPC.
There may not be huge differences among the POWER siblings, but
they're not inter-changeable.
I believe PowerAS adds a few 400-specific instructions and direct
support for the 400's "single level store", with its whopping great
virtual addresses (128 bit).
the issue is what you call power and what you call power/pc. original
power was rios ... absolutely no cache coherency and no capability for
consistent shared memory multiprocessing (live oak was 4-way with
rios.9 chips where virtual memory segments were defined as cacheable
or not cacheable ... aka smp coordination was achieved by forcing
non-cached memory).
somerset was started with motorola and apple ... to do several things
... one was supporting cache consistency and smp. one might claim that
part of power/pc by somerset sort of had 88k bus and cache consistency
applied to an 801 infrastructure. these were the 601, 602, 602, 603,
610, 615, 620, 630, etc. original as/400 port to risc used some flavor
of 6xx chip. 64-bit 620 design meetings had rochester demanding 65-bit
(as opposed to 64-bit) ... where they needed the 65th bit for special
tagging.
when we started ha/cmp (my wife had been manager, 6000 engineering
architecture):
http://www.garlic.com/~lynn/subtopic.html#hacmp
we reported to an executive that then went over to start somerset (he
had originally came from motorola). he got somerset rolling and later
left to become president of mips ... and turn out the 10k.
trusty search engine use turns up as/400 and apple using
power/pc chip
http://c2.com/cgi/wiki?PowerPc
from above:
The chip used in a PowerMac and the IBM eServer pSeries (RS/6000). A
very close variant of PowerPc is also used in the IBM eServer iSeries
(AS/400).
... snip ...
http://www.findarticles.com/p/articles/mi_m0SMG/is_n4_v13/ai_13495730
from above:
The IBM AS/400 will be reborn by the mid-1990s with a new 64-bit
reduced instruction set computing (Risc) microprocessor that will also
run IBM's Unix-based RS/6000 and next-generation Power PC personal
computers, according to a report issued byADM Consulting, Inc.,
... snip ...
http://publib.boulder.ibm.com/iseries/v5r1/ic2924/tstudio/tech_ref/rrmap/
from above:
If your move is a CISC-RISC, see the appropriate 'AS/400 Road Map for
Changing to Power PC Technology' manual for more information.
... snip ..
more trusty search engine use turns up random refs to as/400 power/pc
http://www.notesbench.org/summary.nsf/0/dbac611b63b086208525691400044504?OpenDocument
http://www.geocities.com/SiliconValley/Pines/5581/facts.htm
http://www.notesbench.org/Storage3.nsf/0/c762edfc74b9ce3b8525691000644472?OpenDocument
http://vip400.vtinfo.com/iasp/www/generic/services/hardware/as400e.asp
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: How many layers does TCP/IP architecture really have ?
Newsgroups: comp.protocols.tcp-ip
Date: Wed, 15 Dec 2004 10:28:58 -0700
Tito writes:
Hello. I have read some books and Internet webs, and I see some
authors tells TCP/IP model has 4 layers, others say 5 layers.
This is:
-4 layers:subnet, internet, transport, appplication.
-5 layers: phisic, link, internet, transport, application.
But which is true ? How many layers really ? Where could I find the
TCP/IP offcial reference model ? It exists ?
slightly related:
http://www.garlic.com/~lynn/2004q.html#34
http://www.garlic.com/~lynn/2004q.html#35
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: browser without "padlock" secure?
Newsgroups: comp.os.linux.security
Date: Wed, 15 Dec 2004 14:00:36 -0700
"dmorgan1-with-suffixed-\"1\"-ATdslextreme.com" <dmorgan-with-suffixed-"1"-ATdslextreme.com> writes:
I was about to pay on the internet with a credit card when I noticed
absence of the accustomed closed padlock icon in my browser that
denotes use of https protocol that encrypts the communication. I want
to be sure my credit card info won't travel in the clear.
the locked padlock indicates that https is being used and that the
hos