From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: [Lit.] Buffer overruns Newsgroups: sci.crypt,alt.folklore.computers Date: Mon, 31 Jan 2005 11:34:37 -0700Anne & Lynn Wheeler writes:
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: 4shift schedule Newsgroups: alt.folklore.computers Date: Mon, 31 Jan 2005 11:39:39 -0700there also used to be this joke about having a four shift schedule
... 1st shift in bldg28/sjr on things like
https://www.garlic.com/~lynn/submain.html#systemr
2nd shift in bldg14/15 on disk engineering
https://www.garlic.com/~lynn/subtopic.html#disk
3rd shift in bldg90/stl & bldg29 (vlsi lab) on variety
of things including (high speed data transport):
https://www.garlic.com/~lynn/subnetwork.html#hsdt
and 4th shift (weekends) doing stuff for hone
https://www.garlic.com/~lynn/subtopic.html#hone
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: [Lit.] Buffer overruns Newsgroups: sci.crypt,alt.folklore.computers Date: Mon, 31 Jan 2005 12:18:08 -0700"Tom Linden" writes:
the result was that most codes tended to keep the pipeline only half full (and tended to run along at half the peak MIP rate).
there was a project about 30 years ago that looked at supporting dual i-streams ... somewhat akin to the current hyperthreading work. there would be two instruction addresses, duplicate registers, programmed like a two-processor smp. the instructions and registers in the pipeline would have a one-bit red/black tag indicating which i-stream the operation was associated with. The theory was that two i-streams, each keeping the pipeline half-full might result in aggregate thruput nearly twice the single thread version.
precursor reference to acs ... from the 60s
http://www.cs.clemson.edu/~mark/acs_inst_set.html
eager execution, dual path, multiple path
http://www.cs.clemson.edu/~mark/eager.html
selected historical computer designs
http://www.cs.clemson.edu/~mark/hist.html
a secret computer project in the '60s
https://people.computing.clemson.edu/~mark/acs.html
which is different from the FS secret computer project in the '70s
https://people.computing.clemson.edu/~mark/fs.html
and more drift ... my postings mentioning FS
https://www.garlic.com/~lynn/submain.html#futuresys
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: The mid-seventies SHARE survey Newsgroups: alt.folklore.computers Date: Mon, 31 Jan 2005 12:49:02 -0700glen herrmannsfeldt writes:
the 3330 had 20 surfaces and 20 heads ... however, only 19 platters/heads were addressable. the 20th surface had sector information.
normal 360 CKD dasd operation was
seek
search-id (equal, say cchhr)
tic *-8
read/write
the cchr argument for the search operation was in main memory. in CKD
dasd architecture you could tag a record with some id value (standard
programming tended to use CCHHR type tags). Rather than having
indexes of stuff in memory, it was possible to just know the ID
of the record ... and start an operation that searched for that
record ID.
this architecture traded off real-storage (which was typically in 360 generation terribly constrained ... or at least believed to be terribly constrained) with I/O bandwidth; the search operation would maintain device, controller, and channel dedicated use while it recognized the start of each record, (re)fetched the ID from main memory and compared it to the ID of the record currently rotating under the head. This was horribly expensive in terms of device, controller and channel utilization. However, in the 360 era, it was deemed to be an acceptable trade-off if it saved on needing real storage.
for 3330, the architecture was enhanced if you had a relatively
regular data format; you could know ahead of time the sector location
(rotational position) of the start of the record you wanted. the
ccw sequence then looked something like
seek
set-sector
search-id
tic *-8
read/write
the set-sector operation freed up the control unit and channel (and
possibly string-switch, if one was involved) ... until the sector
location rotated under the 20th head. This could cut the channel and
controller busy in half or better ... potentially doubling the i/o
thruput (in i/o intensive environment).
so the other side is looking at the business ROI ... it turns out that they were shipping standard 3330s as fast as they could make them. Any possible incremental 3330 business that came from retrofitting 3330s to 360s would have to be really significant ... to pull the (scarce) engineers off work on 3330 enhancements, 3350s, 3370s, 3375s, 3380, etc work. The big paying customers were getting a lot larger bang for the buck off the other work the engineers were doing than any possible retrofit that they might do for a relatively few number ofs 360s.
Now on the otherside ... they didn't completely fix CKD dasd (say by converting everything over to fixed-block architecture, FBA).
CP67/VM370/CMS effectively always had an FBA architecture that they were forced to emulate on CKD dasd. There wer significant features of OS/360 genre of operating systems that were dependent on CKD dasd search feature. Both PDS library directories and the master volume VTOC (directory) relied on multi-track search. Rather than maintain indexes (that would require being cached in memory ... tying up real storage), they used multi-track searching to find a unique directory entry out on disk; these records had ids that represented what they indexed, rather than their relative position on disk. Rather than read/cache multi-level of pointers ... they just told the disk to go find the specific directory entry they were interested in.
this design had even more serious impact on channel, controller,
device (and potentially string-switch) busy/utilization.
https://www.garlic.com/~lynn/submain.html#dasd
In the late 70s, i shot a customer performance problem at a large retail batch/online shop (not vm370/cms) ... where they had multiple machines sharing the same large disk farm. It turns out all the machines shared the same application program library ... and during busy period of the day ... all the machines were constantly loading various applications out of the library. Every application load always first reading the directory entry. Reading the directory entry first required searching for it. Each search operation was taking 1/3rd to 1/2 second elapsed time, during which the device, string-switch, controller and channel was busy. The actual application program load was on the order of 30-50mils elapsed time. In addition to the serious resource busy time ... the aggregate cluster of machines was limited to approx. two application program loads per second. There were hundreds of applications in this particular library ... that had aggregate use demand on the order of scores per second not two per second.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Anyone know what the 'clipper' chip looks like ? Newsgroups: sci.crypt Date: Mon, 31 Jan 2005 14:15:57 -0700"Alex Bird" writes:
skipjack encryption:
http://www.cs.technion.ac.il/~biham/Reports/SkipJack/
http://www.powerbasic.com/support/forums/Forum7/HTML/001545.html
http://csrc.nist.gov/encryption/skipjack/skipjack.pdf
http://www.schneier.com/crypto-gram-9807.html#skip
and fortezza were these cards with certificates, preloaded
public/private keys and various onboard crypto algorithms
http://www.mykotronx.com/products/fortezza/index.asp
http://www.rsasecurity.com/rsalabs/node.asp?id=2320
later there was fortezza-ii
http://www.infoworld.com/cgi-bin/displayStory.pl?97115.wnetscape.htm
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: [Lit.] Buffer overruns Newsgroups: sci.crypt,alt.folklore.computers Date: Mon, 31 Jan 2005 15:33:55 -0700Paul Rubin <http://phr.cx@NOSPAM.invalid> writes:
frequently you have browser, firewall, webserver/application, and then database ... both the firewall and the webserver are between the browser machine and the database machine ... the webserver has lan to the firewall and a totally disjoint lan to the database machine.
a common mistake is somebody doing database maintanance ... the web interface is taken down, possibly they enable some other form of remote access, then enable database for changes/administration ... do the updates/changes ... and then forget to lock the database machine down again before re-enabling the web interface.
for the original payment gateway ... way back in the dark ages ... we put in packet filtering router .... for which only a couple things were allowed ... which was connected to a striped-bare machine running application firewall (there was a lot of roll-your-own stuff in this era) ... who's primary duty was checking for length reasonability on incoming requests ... before it got to the machine running the webserver ... which invoked an application ... that in turn forwarded the request to the real processor.
back then one of the most popular routers had a pack filtering specification interface ... where the common failure mode was that the admin specified the inverse of what they had intended. It had to do with the human factors of the specification language. we had two otherwise functional routers from different vendors .... one required 200-300 line specification for the packet filtering rules and the newsgroups had a lots of comments about people specifying the inverse of what they thot they were specifying (aka they were constantly allowing when they thot they were denying) and the other required 20-30 lines to specify the same exact filtering ... and I know of no reported failures where people reported that they had specified the inverse of what they wanted.
later, one of them somewhat featured the really horrible human factors of their specification interface by offering a new GUI that simplified the rule specification ... which would then turn around and generate the actual specification (that people were constantly making mistakes with) which was what was actually loaded into the router.
to slightly bring it back to crypto ... one of the things done for this early payment gateway ... the protocol used SSL between the webserver and the gateway (in part because of the vendor involved) ... but we came up with something referred to as mutual authentication (before there was any specification for anything about mutual authentication)
minor random old ref:
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: [Lit.] Buffer overruns Newsgroups: sci.crypt,alt.folklore.computers Date: Mon, 31 Jan 2005 20:15:27 -0700Paul Rubin <http://phr.cx@NOSPAM.invalid> writes:
so the first thing to do was design and build an automated benchmarking system ... could build new kernels on the fly and reboot and automatically do the next benchmark. all w/o human intervention.
the first 1000 or so benchmarks were sort of chosen to cover the complete domain space (workload, configuration, thruput, options, etc).
an apl program was written ... that took in the results of all benchmarks to date ... and then chose the next set of benchmark characteristics (workload, configuration, options, etc) ... so it could possibly do the next 1000.
the normal kernel service policy put out maintenance updates once a month (including full source). they initially asked me to put out the resource manager on the same schedule. now they had several hundred people ... there was just me to update and integrate resource manager with the latest kernel version and then perform regression tests to validate that they hadn't done something in their kernel maintenance that affected performance. I required at least 100 automatied automated benchmarks that took a minimum of 48hrs elapsed time as part of quality control before releasing a maintenance version. I talked them into that i didn't have to do it more than once every three months (instead of every month).
random related posts on fairshare scheduling, resource manager, etc
https://www.garlic.com/~lynn/subtopic.html#fairshare
https://www.garlic.com/~lynn/subtopic.html#wsclock
misc. posts on automated benchmarking process, workload profiling,
and the early days of capacity planning technology
https://www.garlic.com/~lynn/submain.html#bench
one of the problems was that i specified some synthentic workloads
that were ten times heavier than nominal heavy system load and were
guaranteed to crash the kernel. so before starting the final 3month
validation ... i had to rewrite and restructure all internal kernel
serialization mechanisms which eliminated all the stress testing
induced kernel crashes ... and as it turns out ... all known
occurances of zombie/hung processes. this exercise help later when i
redid the I/O subsystem for the disk engineering lab to eliminate all
system hungs &/or crashes associated with mis-behaving i/o operations.
https://www.garlic.com/~lynn/subtopic.html#disk
and even more later when we were doing ha/cmp
https://www.garlic.com/~lynn/subtopic.html#hacmp
minor related post
https://www.garlic.com/~lynn/95.html#13
for things like 5-nines and 6-nines availability ... during the
project, we coined the terms disaster survivability and geographic
survivability to differentiate from simple disaster/recovery. misc
past posts on business continuity, continuous availability, etc
https://www.garlic.com/~lynn/submain.html#available
now this still wasn't human rated ... for some topic drift, part of an
old thread from 1984 related to Y2k problems (nasa and glancing
reference to human rated systems):
https://www.garlic.com/~lynn/99.html#24
bldg.29/lsg vlsi lab built the LSM (Los gatos Simulation Machine ... or later the Logic State Machine) ... basically used to validate chip design logic. There was a design for the YSE (yorktown simulation engine) and several EVEs built (endicott verification engine). bldg. 86 in San Jose got an EVE ... so there was two chip validation facilities in the san jose area.
in the time-frame involving the development of the RIOS chipset ...
misc. past 801 posts
https://www.garlic.com/~lynn/subtopic.html#801
i was also playing HSDT at the same time ...
https://www.garlic.com/~lynn/subnetwork.html#hsdt
had fiber-optic links, microwave links, traditional telco connections and three TDMA earthstations (one in Yorktown, one in Los Gatos, and one in Austin). Austin chip designs could go over the highspeed satellite link to los gatos and the LSM. There was also a T3 collins digital radio between bldg. 29 and the roof of bldg. 12 on the main plant site ... and there was a microwave link from the roof of bldg.12 to the roof of bldg. 86 ... so could connect bldg 29 and bldg. 86 ... and could also do high speed transmission of RIOS chip designs to the EVE in bldg. 86. HSDT and the use of the San Jose hardware verification were credited with helping bring in RIOS chipset a year early. EVE could handle lot larger chip designs than the several year older LSM. However the LSM had a unique feature, a clock. Most chip verifications engines have assumed synchronous clock ... and so they don't need one ... they just step everything in unison. LSM had a clock and so could handle chips with asynchronous clocking as well as digital chips with analog circuits (thin film magnetic disk heads).
As chips got more & more complex, it started becoming harder and harder to do complete validation.
There was a joint project between a chip company, some people at stanford ... and quite a few mathmaticians located in Moscow (and not Moscow, Idaho) starting in the mid-90s to develop genetic algorithms for chip design validation (some number of patent applications came out of that effort).
misc. past LSM, YSE, and/or EVE posts
https://www.garlic.com/~lynn/2002d.html#3 Chip Emulators - was How does a chip get designed?
https://www.garlic.com/~lynn/2002g.html#55 Multics hardware (was Re: "Soul of a New Machine" Computer?)
https://www.garlic.com/~lynn/2002g.html#77 Pipelining in the past
https://www.garlic.com/~lynn/2002g.html#82 Future architecture
https://www.garlic.com/~lynn/2002j.html#26 LSM, YSE, & EVE
https://www.garlic.com/~lynn/2002l.html#44 Thirty Years Later: Lessons from the Multics Security Evaluation
https://www.garlic.com/~lynn/2003.html#31 asynchronous CPUs
https://www.garlic.com/~lynn/2003k.html#3 Ping: Anne & Lynn Wheeler
https://www.garlic.com/~lynn/2003k.html#14 Ping: Anne & Lynn Wheeler
https://www.garlic.com/~lynn/2003o.html#38 When nerds were nerds
https://www.garlic.com/~lynn/2004j.html#16 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento
https://www.garlic.com/~lynn/2004o.html#25 CKD Disks?
https://www.garlic.com/~lynn/2004o.html#65 360 longevity, was RISCs too close to hardware?
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: [Lit.] Buffer overruns Newsgroups: sci.crypt,alt.folklore.computers Date: Mon, 31 Jan 2005 20:30:33 -0700Anne & Lynn Wheeler writes:
a couple years ago ... one of the major financial transaction systems
credited their 100 percent availability over the previous six years
to two things:
• ims hot-standby
• automated operator
my wife did her stint in pok in charge of loosely-coupled architecture
(aka mainframe for clusters). she was also responsible for Peer-Coupled Shared Data architecture:
https://www.garlic.com/~lynn/submain.html#shareddata
and at the time, the ims hot-standby group was one of the few places that paid her any attention (most of the company was focused on uniprocessor and smp configurations)
automated operator is recognition that people make mistakes.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: The mid-seventies SHARE survey Newsgroups: alt.folklore.computers Date: Tue, 01 Feb 2005 05:41:23 -0700sidd@situ.com () writes:
a much better fix would be to move to an FBA-architecture and start caching directory entries.
a less better fix has been PDSE (partition data set extended)
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: The mid-seventies SHARE survey Newsgroups: alt.folklore.computers Date: Tue, 01 Feb 2005 05:55:48 -0700one of the issues of applying scarce resources to bldg new stuff or niche markets of retrofitting current stuff to old iron aka nominally 360/65s or above, you had to have a customer with reasonably large operation, and they need to buy large amounts of additional dasd and weren't going to migrate to faster, bigger, cheaper 370 to go along with the operation. memory on 360s was much more expensive than 370 memory ... typical 360/65 was 512kbytes ... you could at least migrate to 2-4mbyte 370/155 ... which had much less expensive real memory. However, a growing 360/65 shop that needed a lot more disk space was likely to also need a lot more real storage and memory and was likely to also migrate to 370/165.
note also a lot of the primary 3330 crew ... were part of the 200 disk engineers that migrated with shugart in '69 ... leaving san jose with real shortage of people in the early 70s (it really was scarce disk engineering resources). even in the late 70s, i was being conned into going to high level disk meetings. the excuse they gave was that they still hadn't backfilled all the high-level "system" expertise that they lost in the large shugart exit.
various past shugart postings:
https://www.garlic.com/~lynn/2000.html#9 Computer of the century
https://www.garlic.com/~lynn/2002.html#17 index searching
https://www.garlic.com/~lynn/2002l.html#50 IBM 2311 disk drive actuator and head assembly
https://www.garlic.com/~lynn/2004.html#5 The BASIC Variations
https://www.garlic.com/~lynn/2004j.html#36 A quote from Crypto-Gram
https://www.garlic.com/~lynn/2004l.html#14 Xah Lee's Unixism
https://www.garlic.com/~lynn/2004p.html#0 Relational vs network vs hierarchic databases
https://www.garlic.com/~lynn/2004q.html#64 Will multicore CPUs have identical cores?
https://www.garlic.com/~lynn/2005b.html#1 Foreign key in Oracle Sql
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: [Lit.] Buffer overruns Newsgroups: sci.crypt,alt.folklore.computers Date: Tue, 01 Feb 2005 20:43:35 -0700Brian Inglis writes:
the whole concept of risc & 801 from the mid-70s was that the processor design was significantly simplified and that compiler technology would be used to compensate for the minimalist hardware. It wasn't necessarily that the software using the processor was simple ... in fact the rules for optimizing the machine might be quite complext ... but it was supposedly a software/hardware trade-off ... aka simplifying hardware implementation could be compensated for by much more complex software (and code generation rules).
Some amount of sophisticated code optimization technology from pl.8 spread into pli compiler and libraries.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: The mid-seventies SHARE survey Newsgroups: alt.folklore.computers Date: Tue, 01 Feb 2005 20:51:58 -0700Mike IBM Kingston writes:
Cambridge had six strings of 2314 drives ... the FE assigned to the account decided to color code the controller doors (and spray painted them accordingly). It was much simpler for operations to be told to replace a 2314 pack on a red string or blue string, etc.
Most of the LCS that I was aware of came in 8microsecond variety (which was better than ten times slower).
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: The mid-seventies SHARE survey Newsgroups: alt.folklore.computers Date: Tue, 01 Feb 2005 21:01:22 -0700Peter Flass writes:
there was a little finger paper sensor that would sense when the end of paper occurred ... now normally when that happen, the paper under the type head would be pulled out and last of the fan-fold paper fell to the floor (or possibly stand) ... so it would be pretty evident that you had run out of paper.
however, it was possible for the paper to stick just a little and not be pulled out ... so it wouldn't be evident why the system had hung ... at least not until great frustration (after trying everything else) ... you smashed you fist into the keyboard ... breaking the keyboard ... but also jostling the paper enuf so that it fell loose to the floor and it was now evident what the problem was. At this point the 1052-7 was also broken and a CE had to be called in to repair it.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: [Lit.] Buffer overruns Newsgroups: sci.crypt,alt.folklore.computers Date: Tue, 01 Feb 2005 21:37:54 -0700daw@taverner.cs.berkeley.edu (David Wagner) writes:
However, if the target storage areas have infrastructure determinable sizes ... which isn't dependent on the programmer to provide the target storage area length/size ... then such target storage area length/size could conceivably also be used by a number of buffer related operations also (mitigated the requirement that ABC is required for many buffer operations ... since it becames fairly deterministic that they are going to operate correctly ... since they could be using the same exact size limit construct that would be relied upon by any ABC facility).
My assertion has been that most target storage areas that get overflowed have no determinable size ... and therefor the size must be manufactured by the programmer ... which can lead to mistaken size values which can lead to buffer overflows. If the infrastructure provides no determinable size value for target buffer areas ... then any ABC implementation may also be subject to having the target buffer area size/length provided by the programmer. But if some numbers of the problems are because there are no infrastructure determinable target storage location size/lengths and the infrastructure is at the mercy of the programmer correctly specifying such lengths ... then it is highly likely that any ABC facility could also fail because the programming has incorrectly provided size/length to ABC for target storage area (aka for ABC to correctly work it needs the actual size/length in order to correctly do any bounds checking).
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: [Lit.] Buffer overruns Newsgroups: sci.crypt,alt.folklore.computers Date: Tue, 01 Feb 2005 23:59:12 -0700slight disclaimer ... long ago and far away when i was an undergraduate there were these two products ... a PLI checkout compiler and a PLI optimizing compiler. Products tended to have Ynn-nnnn documents called Program Logic Manual (or PLMs). For some long forgotten reason, I decided to read the PLI checkout compiler's PLM.
One of the things that struck me with reading the PLI checkout compiler PLM is that for doing things like ABC ... the infrastructure needed determinable sizes for structures and storage locations in order to calculate bounds for use in ABC operations. If the infrastructure didn't have determinable lengths and/or sizes for storage areas ... then it was difficult to establish the bounds that any ABC operation might use.
At least in the PLI case, structures and storages areas had determinable lengths &/or sizes and therefor it was possible for ABC to caculate bounds by which to perform ABC operations.
It also turns out that some number of buffer/string operations also tended to use these determinable lengths and/or sizes as part of there standard operation. Given that you could establish the correctness of the library buffer/string operations that utilized these lengths/sizes ... you could be fairly confident that they were at least as correct as the ABC operations that utilized the same length/size constructs.
There is some difficulty in extended ABC operations to environments that includes storages areas that might lack infrastructure determinable lengths and/or sizes ... since it then becomes difficult for ABC to establish any bounds for use in doing ABC operations.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: [Lit.] Buffer overruns Newsgroups: sci.crypt,alt.folklore.computers Date: Wed, 02 Feb 2005 09:06:23 -0700Phil Carmody writes:
i changed the logic to indicate that there was an undefined backing store page for newly created address space ... and logic in the page fault handler to zero ten contiguous registers and perform a BXLE loop with a STM (store-multiple) to zero the page on the fly.
it was part of complete rewrite of the page fault handling code and
inventing a new page replacement algorithm. misc. past posts on
the subject:
https://www.garlic.com/~lynn/subtopic.html#wsclock
ten years later somebody was having trouble getting their stanford phd approved on the technology that i had invented ten years earlier ... in part because it disagreed with some PC academic literature. I was able to provide some direct performance comparisons between implementation of the PC academic literature and my implementation which appeared to help break the impasse over granting the phd.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: [Lit.] Buffer overruns Newsgroups: sci.crypt,alt.folklore.computers Date: Wed, 02 Feb 2005 09:29:23 -0700"Tom Linden" writes:
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: [Lit.] Buffer overruns Newsgroups: sci.crypt,alt.folklore.computers Date: Wed, 02 Feb 2005 09:36:34 -0700"Trevor L. Jackson, III" writes:
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: [Lit.] Buffer overruns Newsgroups: sci.crypt,alt.folklore.computers Date: Wed, 02 Feb 2005 12:28:02 -0700"Tom Linden" writes:
default in cp67 was not have sharing in memory (except for
a hack i'll mention) ... the virtual address space technology
provided a very high degree of isolation (and assurance). some
places like commercial time-sharing services used it
https://www.garlic.com/~lynn/submain.html#timeshare
as well as some gov. TLAs.
360/67 had added virtual memory and features like segment sharing to
basic 360/65 hardware ... but no additional memory protection
features. If you were to provide common, concurrent acccess to the
same virtual page resident in real memory and still provide
protection ... the only store protect feature available on all
360s was the storarge-key based protection mechanism ... extended
discussion on the subject earlier in this thread
https://www.garlic.com/~lynn/2005.html#5 [Lit.} Buffer overruns
https://www.garlic.com/~lynn/2005.html#6 [Lit.} Buffer overruns
this was a problem in cp67 ... as per various previous posts, cp67 attempted to faithfully implemented the 360 principles of operation. Fiddling the storage keys for (system) page protection could interfer with some application use of the same storage key facility in the virtual address space. fetch protection wasn't as much of an issue, since with virtual address space architecture fetch protection can be achieved by just not mapping the pages into the virtual address space (if you can't address the data, then the usual implementation is that you also can't fetch the data). In any case the original cp67 made very little use of sharing the same real pages across multiple different address spaces.
Now there were 1200 people that had been working on tss/360 (the
official corporate operating system for 360/67) that did a page mapped
filesystem and various virtual address sharing paradigms. The people
upstairs on the 5th floor was also doing similar stuff with multics.
In any case, i was a brash young programmer ... and I figured that
anything anybody else could do ... i could also do. So I designed
and implementated page mapped filesystem
https://www.garlic.com/~lynn/submain.html#mmap
and various virtual address space facilities ... although i was forced
to deal with some number of widely used conventions that bound
executable code to specific (virtual or otherwise) address locations
https://www.garlic.com/~lynn/submain.html#adcon
and for a little crypto topic drift ... some people may remember
email addresses with the hostname dockmaster from the 90s (and
some may even remember them from the 80s):
https://www.multicians.org/site-dockmaster.html
other drift:
https://www.garlic.com/~lynn/2001m.html#12 Multics Nostalgia
https://www.garlic.com/~lynn/2001m.html#15 departmental servers
now one of the things that had deviled tss/360 was that they had laid out applications in a very flat structure ... and when the application was invoked it just mapped in the whole structure and pretty much relied on single page fault at a time to fetch the operations. Something like a fortran compiler could be a couple megabyte file ... and running on a 768k real machine with possibly only 60-80 pages left after fixed kernel requirements ... there was a huge amount of page wait in the infrastructure.
cms had essentially borrowed most of the major os/360 applications which had been segmented to fit in small real storage environments ... with transitions between phases that would do block reads for 60kbytes-80kbytes at a time. translating this into a page mapped infrastructure ... the block read requests were translated into page mapped operations with hints for doing block page fetch for all pages in the phase (single page fetch for possibly 10-20 pages at a time).
Now the generalized virtual memory architecture for 370 added a bunch
of stuff learned from 360/67 experience (and others). There was a
bunch of protection features (especially for shared environments) and
various other things like hardware selective invalidates. There were
this series of product concensus meetings in pok involving business
people, software people, and hardware people. As mentioned in several
other posts ... the 370/165 engineers were claiming that if they had
to implement various of the new features (protection mechnisms,
selective invalidates, etc), it would delay the announce of delivery
of 370 virtual memory by six months. Eventually the business decision
was made to drop those additionsl features from the 370 virtual memory
architecture and go with the earlier announce.
https://www.garlic.com/~lynn/2005b.html#62 The mid-seventies SHARE survey
the morphing of cp67/cms to vm370/cms was going to rely on all the new protection mechenisms replacing the storage-key based protection hack that had been used in cp67. however, when it was decided to go across the product line with the 370/165 virtual memory subset ... vm370/cms was forced to revert to the storage-key based protection hack.
we scroll forward a little bit and i've converted my cp67 page mapped file system and enhanced virtual memory management facilities to vm370 ... and the vm370 product group decide to pickup and ship a subset of my virtual memory management facility. In parallel with this, somebody else came up with an alternative shared page protection design. Using the storage-key based protection hack cost cms some performance that could be gained back if it was eliminated. One mechanism was to allow processes to run w/o protection and between task switches ... determine if the active task had corrupted any "protected" pages. If any corrupted protected pages were found ... they were discarded and the system would revert to the uncorrupted copies on disk. Overall, the overhead of this alternative implementation was slightly less than the performance gain from eliminating the storage-key protection hack (when limited to checking 16 virtual shared pages).
The problem was that they shipped this brand new "protection" (actually fix up corruptioin after the fact) at the same time they shipped a subset of my expanded virtual address space use (which at a minimum doubled the typical number of shared pages to 32 ... and frequently to a lot larger number). At checking 32 shared pages (instead of only 16 shared pages), the alternative protection mechanism cost more than was gained from eliminating the storage key based protection hack.
Now we scroll forward a little bit ... and we come to original
relational database implementation
https://www.garlic.com/~lynn/submain.html#systemr
all this work was going on in vm370/cms based operating system environment. You would have a user process address space and a systemr shadow address space of the user process. The shadow process had the protected database stuff that ran on behalf of the user ... but the user didn't have any direct control or access to the shadow. All the shadows could have code that was nominally read-only shared and portions of the shadow address spaces that were read/write shared across all database processes (caching, serialization. commits, locking, etc). This sharing of read/write address space areas was much more of a permission issue than a protection issue (i.e. you only wanted to have trusted processes with sharing of the read/write database virtual memory areas).
So eventually you roll forward to 3033 ... and for the first time you see some mainframe model implementing even a piece of the original 370 virtual memory hardware protection specification.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: [Lit.] Buffer overruns Newsgroups: sci.crypt,alt.folklore.computers Date: Wed, 02 Feb 2005 12:48:59 -0700Brian Inglis writes:
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: [Lit.] Buffer overruns Newsgroups: sci.crypt,alt.folklore.computers Date: Wed, 02 Feb 2005 12:54:10 -0700... oh, part II, somewhat later
vm370 support stuff for unix processes ... somewhat pattern after the tss/370 ssup done for at&t for supporting unix processes.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: [Lit.] Buffer overruns Newsgroups: sci.crypt,alt.folklore.computers Date: Wed, 02 Feb 2005 18:18:19 -0700Paul Rubin <http://phr.cx@NOSPAM.invalid> writes:
random past mutterings about rejecting HSP
https://www.garlic.com/~lynn/subnetwork.html#xtphsp
because it went directly from transport to MAC/LAN ... violating OSI by
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: [Lit.] Buffer overruns Newsgroups: sci.crypt,alt.folklore.computers Date: Wed, 02 Feb 2005 18:30:43 -0700Paul Rubin <http://phr.cx@NOSPAM.invalid> writes:
although in my brash youth i was drawn to the exercise of re-arrainging totally unrelated code in the kernel so that some desired result might happen purely as side-effect of totally unrelated activity ... and therefor claim i could implement kernel function in zero lines of code.
of course this could come back to bite your 5-10 years later with somebody else doing kernel change and perturbing the carefully orchistrated arrangement. part of the problem is these newer generations never bother to learn the fine art of codeless implementations, they tend to prefer very straight forward cause & effect.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Volume Largest Free Space Problem... ??? Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Wed, 02 Feb 2005 21:43:12 -0700shmuel+ibm-main@ibm-main.lst (Shmuel Metz , Seymour J.) writes:
one of the engineers that went to memorex and latter formed BLI claimed to have been an engineer on the 2321.
random other posts about dasd
https://www.garlic.com/~lynn/submain.html#dasd
and totally unrelated posts about dasd engineering and product
test labs in bldgs 14 & 15:
https://www.garlic.com/~lynn/subtopic.html#disk
random past posts mentioning 2321
https://www.garlic.com/~lynn/2000b.html#41 How to learn assembler language for OS/390 ?
https://www.garlic.com/~lynn/2000.html#9 Computer of the century
https://www.garlic.com/~lynn/2001.html#17 IBM 1142 reader/punch (Re: First video terminal?)
https://www.garlic.com/~lynn/2001.html#51 Competitors to SABRE?
https://www.garlic.com/~lynn/2001l.html#63 MVS History (all parts)
https://www.garlic.com/~lynn/2002f.html#3 Increased Paging in 64-bit
https://www.garlic.com/~lynn/2002g.html#84 Questions on IBM Model 1630
https://www.garlic.com/~lynn/2002.html#16 index searching
https://www.garlic.com/~lynn/2002.html#22 index searching
https://www.garlic.com/~lynn/2002i.html#26 : Re: AS/400 and MVS - clarification please
https://www.garlic.com/~lynn/2002i.html#31 : Re: AS/400 and MVS - clarification please
https://www.garlic.com/~lynn/2002i.html#33 "Mass Storage System"
https://www.garlic.com/~lynn/2002m.html#40 Wanted: the SOUNDS of classic computing
https://www.garlic.com/~lynn/2002o.html#3 PLX
https://www.garlic.com/~lynn/2002o.html#9 PLX
https://www.garlic.com/~lynn/2003b.html#7 Disk drives as commodities. Was Re: Yamhill
https://www.garlic.com/~lynn/2003b.html#9 Disk drives as commodities. Was Re: Yamhill
https://www.garlic.com/~lynn/2003b.html#18 Card Columns
https://www.garlic.com/~lynn/2003c.html#36 "average" DASD Blocksize
https://www.garlic.com/~lynn/2003.html#70 Disk drives as commodities. Was Re: Yamhill
https://www.garlic.com/~lynn/2003.html#72 Disk drives as commodities. Was Re: Yamhill
https://www.garlic.com/~lynn/2003k.html#36 What is timesharing, anyway?
https://www.garlic.com/~lynn/2003m.html#6 The real history of comp arch: the short form
https://www.garlic.com/~lynn/2003m.html#42 S/360 undocumented instructions?
https://www.garlic.com/~lynn/2003n.html#39 DASD history
https://www.garlic.com/~lynn/2004e.html#41 Infiniband - practicalities for small clusters
https://www.garlic.com/~lynn/2004.html#5 The BASIC Variations
https://www.garlic.com/~lynn/2004.html#6 The BASIC Variations
https://www.garlic.com/~lynn/2004l.html#18 FW: Looking for Disk Calc program/Exec
https://www.garlic.com/~lynn/2004p.html#0 Relational vs network vs hierarchic databases
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: [Lit.] Buffer overruns Newsgroups: sci.crypt,alt.folklore.computers Date: Wed, 02 Feb 2005 22:28:17 -0700"Tom Linden" writes:
direct access to the zeros page area required special raw disk permission ... even special permission for r/o raw disk permission of that disk area.
also as mentioned, i changed it fairly early on to an instruction loop (the instruction loop was shorter than the pathlength to do a page i/o operation) ... and even as an undergraduate ... they got to be fairly good at shipping my code in the product.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: [Lit.] Buffer overruns Newsgroups: alt.folklore.computers Date: Thu, 03 Feb 2005 08:31:37 -0700Anne & Lynn Wheeler writes:
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: [Lit.] Buffer overruns Newsgroups: sci.crypt,alt.folklore.computers Date: Thu, 03 Feb 2005 12:29:04 -0700"Charlie Gibbs" writes:
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: [Lit.] Buffer overruns Newsgroups: sci.crypt,alt.folklore.computers Date: Thu, 03 Feb 2005 22:12:31 -0700cmadams@hiwaay.net (Chris Adams) writes:
"lazy" swap tends to be sort of like no-dup ... but only for the initial allocation. you can still overcommit a no-dup policy ... but it gives a little bit better breathing room. i ran into a number of unixes during the 90s that had "lazy" swap but a dup policty (once allocated) and would bring themselves down. System initially booted, some number of demons and other processors initialized and when to sleep. application came along and started running ... forcing all the pages for these startup routines to disk. the application is running fine ... but "lazy" swap hasn't yet allocated any space. some of the demons start to wake up and are being brought into memory ... which starts forcing application pages out. The system hangs at this point since there hasn't been enuf page space on disk allocated for a "dup" policy ... but there would have been sufficient space if system was able to dynamically switch to a "no-dup" policy. One could claim that while dup policy was in-force, that a system could be quite a bit more liberal in its allocation strategy ... but at a point where it was forced from dup to no-dup policy ... it would start becoming quite a bit more conservative.
In the "dup" policy ... you eventually need to have enuf disk space for all pages that might exist. In a "no-dup" policy, the total number of pages supportable is the combination of the allocated disk space plus the pageable real memory. A "dup" policy might advise allocated twice as much disk space for pages as there is real memory. A "no-dup" policy might get along fine with the same amount of disk space as there is real memory.
for some thread drift ... some amount about page replacement
algorithms that i had originated as undergraduate in the '60s
https://www.garlic.com/~lynn/subtopic.html#wsclock
some number of past threads on dup/no-dup allocation policie
https://www.garlic.com/~lynn/93.html#12 managing large amounts of vm
https://www.garlic.com/~lynn/93.html#13 managing large amounts of vm
https://www.garlic.com/~lynn/94.html#9 talk to your I/O cache
https://www.garlic.com/~lynn/2000d.html#13 4341 was "Is a VAX a mainframe?"
https://www.garlic.com/~lynn/2001i.html#42 Question re: Size of Swap File
https://www.garlic.com/~lynn/2001l.html#55 mainframe question
https://www.garlic.com/~lynn/2001n.html#78 Swap partition no bigger than 128MB?????
https://www.garlic.com/~lynn/2002b.html#10 hollow files in unix filesystems?
https://www.garlic.com/~lynn/2002b.html#16 hollow files in unix filesystems?
https://www.garlic.com/~lynn/2002b.html#19 hollow files in unix filesystems?
https://www.garlic.com/~lynn/2002b.html#20 index searching
https://www.garlic.com/~lynn/2002e.html#11 What are some impressive page rates?
https://www.garlic.com/~lynn/2002f.html#20 Blade architectures
https://www.garlic.com/~lynn/2002f.html#26 Blade architectures
https://www.garlic.com/~lynn/2003f.html#5 Alpha performance, why?
https://www.garlic.com/~lynn/2003o.html#62 1teraflops cell processor possible?
https://www.garlic.com/~lynn/2004g.html#17 Infiniband - practicalities for small clusters
https://www.garlic.com/~lynn/2004g.html#18 Infiniband - practicalities for small clusters
https://www.garlic.com/~lynn/2004g.html#20 Infiniband - practicalities for small clusters
https://www.garlic.com/~lynn/2004h.html#19 fast check for binary zeroes in memory
https://www.garlic.com/~lynn/2004i.html#1 Hard disk architecture: are outer cylinders still faster than inner cylinders?
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: [Lit.] Buffer overruns Newsgroups: sci.crypt,alt.folklore.computers Date: Thu, 03 Feb 2005 22:39:21 -0700daw@taverner.cs.berkeley.edu (David Wagner) writes:
as i previously mentioned the exploit descriptions are relatively free-form and unstructured ... and there doesn't seem to be any uniform process about the descriptions ... sometimes describing the cause and sometimes describing the results and sometimes describing both. My original analysis was from nearly a year ago and I made some numbers of postings about the difficulty of cause determination ... recently there has been some statements that they will start using more structure process for CVE entries.
From last year, I eventually did word and word pair frequency analysis
... buffer overruns showed up in about 1/5th of the CVE exploit
descriptions .... posting from nearly year ago about analysis of CVE
entries (note this isn't about the percentage of buffer overrun bugs,
this is the percentage of exploits that involved buffer overruns):
https://www.garlic.com/~lynn/2004e.html#43 security taxonomy and CVE
a much more recent posting in this thread
https://www.garlic.com/~lynn/2005b.html#20 [Lit.] Buffer overruns
observes that the Feb. 2005 linux magazine has an article quoting NIST as saying that for the exploited vulnerabilities (871) that they have studied for the past four years, 20 percent of the exploited vulnerabilities involved buffer overrun vulnerabilities (which was about the same percentage I came up with by doing word-pair frequency analysis on the CVE entries).
I've also observed that the buffer overrun vulnerabilities exploits
have apparently been deemed serious enuf that special hardware has
been developed to address the buffer overrun exploits issue (not
preventing the overruns ... but preventing that the overrun
vulnerabilities will lead to system compromises). some recent postings
discussion the no execute hardware and windows XP support for it
designed to address buffer overrun vulnerability exploits:
https://www.garlic.com/~lynn/2005.html#0 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005.html#1 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005.html#3 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005.html#5 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005.html#32 8086 memory space [was: The Soul of Barb's New Machine]
https://www.garlic.com/~lynn/2005b.html#25 360POO
https://www.garlic.com/~lynn/2005b.html#39 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005b.html#66 [Lit.] Buffer overruns
newer types of attacks and exploits seem to be evolving ... there had been something in 1999 about buffer overruns being the majority (i.e. the number of buffer overrun vulnerabilities exploits may not have actually decreased ... there may just be an increase in other kinds of exploits and attacks).
I also noted that something about buffer overrun vulnerability
exploits seemed to have spawned at least three books (just doing a
search on amazon.com titles for buffer overflow attack). recent posting
about papers, books, etc.
https://www.garlic.com/~lynn/2005b.html#42 [Lit.] Buffer overruns
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: [Lit.] Buffer overruns Newsgroups: sci.crypt,alt.folklore.computers Date: Fri, 04 Feb 2005 07:55:40 -0700Randy Howard writes:
repeat of a prior reference:
http://www.theregister.co.uk/2004/12/24/amd_dutch_ads
a reference from above:
http://dictionary.reference.com/search?q=buffer%20overflow
related to ABC and buffer overflow ... a prereq for ABC operations is that the infrastructure have access to determinable length values for the storage areas that ABC operations will be applied to.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: [Lit.] Buffer overruns Newsgroups: sci.crypt,alt.folklore.computers Date: Fri, 04 Feb 2005 08:10:44 -0700Randy Howard writes:
note however, the prevalence and significant of the exploits and compromises because of buffer overflow problems appear to have been deemed significant enuf that specialized hardware and software was created as countermeasure. Given that one of the exploit mechanisms involve storage areas in the c language that lack infrastructure determinable length areas ... the specialized hardware is not an ABC mechanism (lack any determinable length on which to base a bounds checking methodology) ... they just mark all such storage areas as non-executable as a countermeasure to common exploit/compromise of buffer overflow vulnerability.
misc. references to specialized hardware and software countermeasure
for buffer overflow exploits:
https://www.garlic.com/~lynn/2005.html#0 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005.html#1 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005.html#3 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005.html#5 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005.html#32 8086 memory space [was: The Soul of Barb's New Machine]
https://www.garlic.com/~lynn/2005b.html#25 360POO
https://www.garlic.com/~lynn/2005b.html#39 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005b.html#66 [Lit.] Buffer overruns
minor reference from one of the above
http://hardware.mcse.ms/message13436-4.html
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: XML Encryption Newsgroups: sci.crypt Date: Fri, 04 Feb 2005 08:29:58 -0700alastairgarrow@aol.com (Alastair Garrow) writes:
the digital certificate paradigm was developed for environments where the recipient would have had no prior contact and/or previous knowledge of the sender ... and was a method of distributing the sender's public key to such recipients (when the recipient would have had to prior reason, occasion, and/or opportunity for obtaining the sender's public key).
in the mid-90s this technology was applied to financial transactions between a consumer and their financial institution. Now, in general, a person has an account with their financial institution ... which violates a basic premise of the original design point for digital certificates. Another characteristics was that any attached digital certificate could be two orders of magnitude larger than the basic common financial transaction message size. As a result, the attachment of such digital certificates was not only redundant and superfluous but also served primarily to increase the financial transaction message size by two orders of magnitude.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: [Lit.] Buffer overruns Newsgroups: sci.crypt,alt.folklore.computers Date: Fri, 04 Feb 2005 08:54:37 -0700Randy Howard writes:
with truncated & sorted extraction of part of sentences from descriptions in CVE database involving buffer overflow .. a large amount of these programs appear to be relatively recent and represent a spectrum of programs across both open source and non-open source.
Buffer overflow and denial of service in Buffer overflow in /usr/bin/cu in Solari Buffer overflow in AIX and Solaris ""get Buffer overflow in AIX dtterm program fo Buffer overflow in AIX ftpd in the libc Buffer overflow in AIX lchangelv gives r Buffer overflow in AIX lquerylv program Buffer overflow in AIX rcp command allow Buffer overflow in AIX writesrv command Buffer overflow in AIX xdat gives root a Buffer overflow in AOL Instant Messenger Buffer overflow in AOL Instant Messenger Buffer overflow in AOLserver 3.0 allows Buffer overflow in ASP Server-Side Inclu Buffer overflow in ASP.NET Worker Proces Buffer overflow in Accept command in Net Buffer overflow in Analog before 4.16 al Buffer overflow in AnalogX SimpleServer: Buffer overflow in AnalogX SimpleServer: Buffer overflow in AnalogX SimpleServer: Buffer overflow in AspUpload.dll in Pers Buffer overflow in AuthFilter ISAPI filt Buffer overflow in AuthFilter ISAPI filt Buffer overflow in BEA WebLogic server p Buffer overflow in BFTelnet allows remot Buffer overflow in BIND 8.2 via NXT reco Buffer overflow in BNC IRC proxy allows Buffer overflow in BNU UUCP daemon (uucp Buffer overflow in BSD and linux lpr com Buffer overflow in BSD line printer daem Buffer overflow in BSD-based lpr package Buffer overflow in BSD-based telnetd tel Buffer overflow in Berkeley automounter Buffer overflow in BitchX IRC client all Buffer overflow in CDE Calendar Manager Buffer overflow in CProxy 3.3 allows rem Buffer overflow in CSAdmin module in Cis Buffer overflow in CSM mail server allow Buffer overflow in CamShot WebCam HTTP s Buffer overflow in Canna input system al Buffer overflow in Cisco 7xx routers thr Buffer overflow in Cisco TACACS+ tac_plu Buffer overflow in CiscoSecure ACS Serve Buffer overflow in Common Desktop Enviro Buffer overflow in CommuniGatePro via a Buffer overflow in Compaq Management Age Buffer overflow in CrackLib 2.5 may allo Buffer overflow in Dalnet IRC server 4.6 Buffer overflow in Darxite 0.4 and earli Buffer overflow in Dosemu Slang library Buffer overflow in EFTP allows remote at Buffer overflow in EFTP allows remote at Buffer overflow in Elm 2.5.5 and earlier Buffer overflow in Embedded Support Part Buffer overflow in Eterm of Enlightenmen Buffer overflow in Exim allows local use Buffer overflow in Flash OCX for Macrome Buffer overflow in FreeBSD angband allow Buffer overflow in FreeBSD fts library r Buffer overflow in FreeBSD libmytinfo li Buffer overflow in FreeBSD lpd through l Buffer overflow in FreeBSD setlocale in Buffer overflow in FreeBSD xmindpath all Buffer overflow in Frox transparent FTP Buffer overflow in Fujitsu Chocoa IRC cl Buffer overflow in FuseMAIL POP service Buffer overflow in Getkey in the protoco Buffer overflow in Gnomelib in SuSE Linu Buffer overflow in GoodTech Telnet Serve Buffer overflow in GuildFTPd Server 0.97 Buffer overflow in HP Openview Network N Buffer overflow in HP-UX newgrp program Buffer overflow in HPUX passwd command a Buffer overflow in HTML parser of the Lo Buffer overflow in HTTP Proxy for Symant Buffer overflow in Half Life dedicated s Buffer overflow in Hilgraeve, Inc. Hyper Buffer overflow in HylaFAX faxgetty befo Buffer overflow in IBM HomePagePrint 1.0 Buffer overflow in IBM Net.Data db2www C Buffer overflow in IBM WebSphere web app Buffer overflow in ICQ before 2001B Beta Buffer overflow in IIS 4.0 allows remote Buffer overflow in IMAP server in Netsca Buffer overflow in INN 2.2.1 and earlier Buffer overflow in INN inews program. Buffer overflow in IPSEC authentication Buffer overflow in IPSwitch IMail SMTP s Buffer overflow in ISAPI extension (idq. Buffer overflow in ISS BlackICE Defender Buffer overflow in ITHouse mail server 1 Buffer overflow in InetServ 3.0 allows r Buffer overflow in Infopulse Gatekeeper Buffer overflow in Infoseek Ultraseek se Buffer overflow in Intel InBusiness eMai Buffer overflow in Internet Explorer 4.0 Buffer overflow in Internet Explorer 4.0 Buffer overflow in Internet Explorer 5 a Buffer overflow in Internet Explorer 5 d Buffer overflow in Internet Information Buffer overflow in Internet Mail Connect Buffer overflow in Internet Mail Service Buffer overflow in Internet Printing ISA Buffer overflow in IrDA driver providing Buffer overflow in KDE Kmail allows a re Buffer overflow in KDE kdesud on Linux a Buffer overflow in Kerberos 4 KDC progra Buffer overflow in Kermit communications Buffer overflow in Korn Shell (ksh) suid Buffer overflow in L0pht AntiSniff allow Buffer overflow in Linux Slackware crond Buffer overflow in Linux cdrecord allows Buffer overflow in Linux mount and umoun Buffer overflow in Linux splitvt 1.6.3 a Buffer overflow in Linux splitvt command Buffer overflow in Linux xinetd 2.1.8.9p Buffer overflow in Lotus Domino HTTP ser Buffer overflow in Lotus Domino Mail Ser Buffer overflow in Lotus Notes LDAP (NLD Buffer overflow in Lynx 2.x allows remot Buffer overflow in MDBMS database server Buffer overflow in MDaemon POP server al Buffer overflow in MERCUR SMTP server 3. Buffer overflow in Mediahouse Statistics Buffer overflow in Mercury MTA POP3 serv Buffer overflow in Microsoft Clip Art Ga Buffer overflow in Microsoft FrontPage S Buffer overflow in Microsoft Index Serve Buffer overflow in Microsoft MSN Chat Ac Buffer overflow in Microsoft Outlook and Buffer overflow in Microsoft Phone Book Buffer overflow in Microsoft Phone Diale Buffer overflow in Microsoft Rich Text F Buffer overflow in Microsoft Telnet clie Buffer overflow in Microsoft Terminal Se Buffer overflow in Microsoft Visual Stud Buffer overflow in Microsoft Windows Med Buffer overflow in Microsoft Windows Med Buffer overflow in Microsoft Windows Med Buffer overflow in Microsoft command pro Buffer overflow in Multiple UNC Provider Buffer overflow in NCSA HTTP daemon v1.3 Buffer overflow in NFS mountd gives root Buffer overflow in NFS server on Linux a Buffer overflow in NIS+, in Sun's rpc.ni Buffer overflow in NLS (Natural Language Buffer overflow in NetMeeting allows den Buffer overflow in NetScreen Firewall We Buffer overflow in Netscape Communicator Buffer overflow in Netscape Communicator Buffer overflow in Netscape Directory Se Buffer overflow in Netscape Enterprise S Buffer overflow in Netscape Enterprise S Buffer overflow in Netsnap webcam HTTP s Buffer overflow in Netwin WebNews CGI pr Buffer overflow in Norton Antivirus for Buffer overflow in Novell GroupWise 6.0. Buffer overflow in Novell iManager (eMFr Buffer overflow in OSF Distributed Compu Buffer overflow in OmniHTTPd CGI program Buffer overflow in OpenBSD ping. Buffer overflow in OpenBSD procfs and fd Buffer overflow in OpenLink 3.2 allows r Buffer overflow in OpenSSH before 2.9.9, Buffer overflow in Oracle9iAS Web Cache Buffer overflow in OverView5 CGI program Buffer overflow in PHP cgi program, php. Buffer overflow in POP servers based on Buffer overflow in PerlIS.dll in Actives Buffer overflow in Platinum Policy Compl Buffer overflow in Pragma Systems Telnet Buffer overflow in Qpopper (popper) 4.0. Buffer overflow in RSAREF2 via the encry Buffer overflow in Real Networks RealPla Buffer overflow in RealJukebox 2 1.0.2.3 Buffer overflow in RealNetworks RealServ Buffer overflow in RegAPI.DLL used by Wi Buffer overflow in Remote Access Service Buffer overflow in Remote Access Service Buffer overflow in SCO scohelp program a Buffer overflow in SGI IRIX mailx progra Buffer overflow in SLmail 3.x allows att Buffer overflow in SMTP service of Lotus Buffer overflow in SNMP daemon (snmpd) o Buffer overflow in Samba smbd program vi Buffer overflow in SeaNox Devwex allows Buffer overflow in Sendmail before 8.12. Buffer overflow in Serv-U FTP 2.5 allows Buffer overflow in Serv-U FTP server whe Buffer overflow in Simple Network Time S Buffer overflow in Skyfull mail server v Buffer overflow in Small HTTP Server all Buffer overflow in SmartDesk WebSuite al Buffer overflow in SmartMax MailMax POP3 Buffer overflow in Solaris 7 lp allows l Buffer overflow in Solaris dtprintinfo p Buffer overflow in Solaris fdformat comm Buffer overflow in Solaris getopt in lib Buffer overflow in Solaris kcms_configur Buffer overflow in Solaris lpset program Buffer overflow in Solaris netpr program Buffer overflow in Solaris sadmind allow Buffer overflow in Solaris snmpXdmid SNM Buffer overflow in Solaris snoop allows Buffer overflow in Solaris snoop program Buffer overflow in Solaris x86 mkcookie Buffer overflow in Source Code Browser P Buffer overflow in StarOffice StarSchedu Buffer overflow in Sun ONE / iPlanet Web Buffer overflow in Sun's ping program ca Buffer overflow in SunFTP build 9(1) all Buffer overflow in SunOS/Solaris ps comm Buffer overflow in SysVInit in Red Hat L Buffer overflow in TNS Listener for Orac Buffer overflow in TT_SESSION environmen Buffer overflow in Thomas Boutell's cgic Buffer overflow in Tinyproxy HTTP proxy Buffer overflow in ToxSoft NextFTP clien Buffer overflow in Trend Micro Virus Bus Buffer overflow in Trivial HTTP (THTTPd) Buffer overflow in TrollFTPD 1.26 and ea Buffer overflow in Universal Plug and Pl Buffer overflow in University of Minneso Buffer overflow in University of Washing Buffer overflow in University of Washing Buffer overflow in University of Washing Buffer overflow in UnixWare i2odialogd d Buffer overflow in UnixWare ppptalk comm Buffer overflow in UnixWare rtpm program Buffer overflow in UnixWare xauto progra Buffer overflow in VB-TSQL debugger obje Buffer overflow in VDO Live Player allow Buffer overflow in VMWare 1.0.1 for Linu Buffer overflow in VMware Authorization Buffer overflow in Van Dyke SecureCRT SS Buffer overflow in Vixie Cron library up Buffer overflow in Vixie Cron on Red Hat Buffer overflow in Vixie cron 3.0.1-56 a Buffer overflow in Voyager web administr Buffer overflow in WFTPD FTP server allo Buffer overflow in WS_FTP FTP Server 3.1 Buffer overflow in WU-FTPD and related F Buffer overflow in WU-FTPD and related F Buffer overflow in War FTP allows remote Buffer overflow in War FTPd 1.6x allows Buffer overflow in WebActive HTTP Server Buffer overflow in WebBBS 1.15 allows re Buffer overflow in WebShield SMTP 4.5.44 Buffer overflow in Webfind CGI program i Buffer overflow in Webstar HTTP server a Buffer overflow in WinZip 8.0 allows att Buffer overflow in Winamp 2.64 and earli Buffer overflow in WindowMaker (aka wmak Buffer overflow in Windows 2000 event vi Buffer overflow in Windows NT 4.0 help f Buffer overflow in Windows Shell (used a Buffer overflow in Winhlp32.exe allows r Buffer overflow in X server (Xsco) in Op Buffer overflow in X11 dissector in Ethe Buffer overflow in XFree86 3.3.x allows Buffer overflow in Xi Graphics Accelerat Buffer overflow in Xshipwars xsw program Buffer overflow in Xsun X server in Sola Buffer overflow in Xsun in Solaris 8 and Buffer overflow in Xt library of X Windo Buffer overflow in Yamaha MidiPlug via a Buffer overflow in ZBServer Pro allows r Buffer overflow in a legacy ActiveX cont Buffer overflow in a system function tha Buffer overflow in aVirt Rover POP3 serv Buffer overflow in arp command in Solari Buffer overflow in bash 2.0.0, 1.4.17, a Buffer overflow in bftp daemon (bftpd) 1 Buffer overflow in bing allows remote at Buffer overflow in bootpd 2.4.3 and earl Buffer overflow in calserver in SCO Open Buffer overflow in catopen() function in Buffer overflow in cb_reset in the Syste Buffer overflow in cfingerd allows local Buffer overflow in chkey in Solaris 2.5. Buffer overflow in cmctl program in Orac Buffer overflow in cpr for the eoe.sw.cp Buffer overflow in curl earlier than 6.0 Buffer overflow in dc20ctrl before 0.4_1 Buffer overflow in digest command in IBM Buffer overflow in dlvr_audit for Calder Buffer overflow in dmplay in IRIX 6.2 an Buffer overflow in dsh in dqs 3.2.7 in S Buffer overflow in dtterm in HP-UX 11.0 Buffer overflow in dvtermtype in Tridia Buffer overflow in eDonkey 2000 35.16.60 Buffer overflow in eeprom in Solaris 2.5 Buffer overflow in efingerd 1.5 and earl Buffer overflow in enq command in IBM AI Buffer overflow in exrecover in Solaris Buffer overflow in fdmount on Linux syst Buffer overflow in ffbconfig in Solaris Buffer overflow in free internet chess s Buffer overflow in glob function of glib Buffer overflow in gnuplot in Linux vers Buffer overflow in healthd for FreeBSD a Buffer overflow in httpGets function in Buffer overflow in hybrid-6 IRC server c Buffer overflow in iMesh 1.02 allows rem Buffer overflow in imwheel allows local Buffer overflow in index.cgi administrat Buffer overflow in innd 2.2.2 allows rem Buffer overflow in ippRead function of C Buffer overflow in ircII 4.4 IRC client Buffer overflow in ja-xklock 2.7.1 and e Buffer overflow in jaZip Zip/Jaz drive m Buffer overflow in kdc_reply_cipher of l Buffer overflow in krb425_conv_principal Buffer overflow in krb_rd_req function i Buffer overflow in krshd in Kerberos 5 a Buffer overflow in ksu in Kerberos 5 all Buffer overflow in libi18n library in IB Buffer overflow in licq 1.0.4 and earlie Buffer overflow in line printer daemon ( Buffer overflow in linuxconf 1.11r11-rh2 Buffer overflow in listmanager earlier t Buffer overflow in listserv allows arbit Buffer overflow in logging functions of Buffer overflow in login in various Syst Buffer overflow in lpstat in IRIX 6.2 an Buffer overflow in lukemftp FTP client i Buffer overflow in mail command in Solar Buffer overflow in mail included with Su Buffer overflow in mailx in Solaris 8 an Buffer overflow in man program in various Buffer overflow in mana in OpenServer 5. Buffer overflow in mhshow in the Linux n Buffer overflow in micq client 0.4.6 and Buffer overflow in mopd (Maintenance Ope Buffer overflow in mtr 0.46 and earlier, Buffer overflow in mutt mail client allo Buffer overflow in ncurses 5.0, and the Buffer overflow in ndcfg command for Uni Buffer overflow in newt.c of newt window Buffer overflow in nftp FTP client versi Buffer overflow in nnrpd program in INN Buffer overflow in nslookupComplain func Buffer overflow in nss_nisplus.so.1 libr Buffer overflow in ntpd ntp daemon 4.0.9 Buffer overflow in ntping in scotty 2.1. Buffer overflow in otrcrep in Oracle 8.0 Buffer overflow in pam_localuser PAM mod Buffer overflow in ping in AIX 4.2 and e Buffer overflow in piobe command in IBM Buffer overflow in pioout command in IBM Buffer overflow in pks PGP public key we Buffer overflow in ppp program in FreeBS Buffer overflow in procmail before versi Buffer overflow in ptexec in the Sun Val Buffer overflow in qpopper (aka qpop or Buffer overflow in remote web administra Buffer overflow in rpc.yppasswdd (yppass Buffer overflow in rpc.yppasswdd allows Buffer overflow in rwcgi60 CGI program f Buffer overflow in sccw allows local use Buffer overflow in search.cgi in mnoGoSe Buffer overflow in setclock command in I Buffer overflow in setsenv command in IB Buffer overflow in ssh 1.2.26 client wit Buffer overflow in sshd in OpenSSH 2.3.1 Buffer overflow in ssinc.dll in IIS 5.0 Buffer overflow in statd allows root pri Buffer overflow in strong.exe program in Buffer overflow in su in Tru64 Unix 5.x Buffer overflow in sudo earlier than 1.6 Buffer overflow in suidperl (sperl), Per Buffer overflow in syslog utility allows Buffer overflow in tab expansion capabil Buffer overflow in telnet daemon tgetent Buffer overflow in telnet server in Wind Buffer overflow in the ""Super"" utility Buffer overflow in the ASP data transfer Buffer overflow in the AddSuLog function Buffer overflow in the CyberPatrol daemo Buffer overflow in the ESMTP service of Buffer overflow in the FTP client in the Buffer overflow in the GUI authentication Buffer overflow in the HTML interpreter Buffer overflow in the HTML library used Buffer overflow in the HTML parser for N Buffer overflow in the HTML parsing code Buffer overflow in the HTTP proxy server Buffer overflow in the ISAPI DLL filter Buffer overflow in the InterAccess telne Buffer overflow in the LDAP component of Buffer overflow in the Linux binary comp Buffer overflow in the Linux mail progra Buffer overflow in the Mail-Max SMTP ser Buffer overflow in the NetWare remote we Buffer overflow in the NetWin DSMTP 2.7q Buffer overflow in the Office Web Compon Buffer overflow in the OpenDataSource fu Buffer overflow in the POP server POProx Buffer overflow in the SHTML logging fun Buffer overflow in the SMTP gateway for Buffer overflow in the SQLXML ISAPI exte Buffer overflow in the Still Image Servi Buffer overflow in the System Monitor Ac Buffer overflow in the Transact-SQL (T-S Buffer overflow in the Web Archives comp Buffer overflow in the Web Messaging dae Buffer overflow in the Window.External f Buffer overflow in the Xview library as Buffer overflow in the automatic mail ch Buffer overflow in the chunked encoding Buffer overflow in the chunked encoding Buffer overflow in the client connection Buffer overflow in the conversion utilit Buffer overflow in the dump utility in t Buffer overflow in the dvwssr.dll DLL in Buffer overflow in the huh program in th Buffer overflow in the implementation of Buffer overflow in the ism.dll ISAPI ext Buffer overflow in the kcsSUNWIOsolf.so Buffer overflow in the kdc_reply_cipher Buffer overflow in the libauth library i Buffer overflow in the line printer daem Buffer overflow in the logging feature o Buffer overflow in the man program in Li Buffer overflow in the parsing mechanism Buffer overflow in the pop-2d POP daemon Buffer overflow in the preprocessor in g Buffer overflow in the web administratio Buffer overflow in the web archive compo Buffer overflow in the web interface for Buffer overflow in the web interface for Buffer overflow in the web server for No Buffer overflow in the wmcdplay CD playe Buffer overflow in traffic_manager for I Buffer overflow in transaction signature Buffer overflow in ufsrestore in Solaris Buffer overflow in uidadmin in Caldera O Buffer overflow in ultimate_source funct Buffer overflow in uuq in AIX 4 could al Buffer overflow in various Microsoft app Buffer overflow in various decoders in E Buffer overflow in vchkpw/vpopmail POP a Buffer overflow in vqSoft vqServer 1.4.4 Buffer overflow in w3-msql CGI program i Buffer overflow in w3m 0.2.1 and earlier Buffer overflow in wconsole.dll in Rockl Buffer overflow in webd in Network Fligh Buffer overflow in wmcube-gdk for WMCube Buffer overflow in ximp40 shared library Buffer overflow in xlib in XFree 3.3.x p Buffer overflow in xlock program allows Buffer overflow in xlockmore xlock progr Buffer overflow in xmcd 2.0p12 allows lo Buffer overflow in xpilot-server for XPi Buffer overflow in ypbind 3.3 possibly a Buffer overflow in ypserv in Mandrake Li Buffer overflow of rlogin program using Buffer overflows in (1) php_mime_split i Buffer overflows in HP Software Distribu Buffer overflows in Linux cdwtools 093 a Buffer overflows in Mars NetWare Emulati Buffer overflows in Sun libnsl allow roo Buffer overflows in Windows NT 4.0 print Buffer overflows in lpspooler in the fil Buffer overflows in muxatmd in AIX 4 all Buffer overflows in ntop running in web Buffer overflows in wuarchive ftpd (wu-f--
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: [Lit.] Buffer overruns Newsgroups: sci.crypt,alt.folklore.computers Date: Fri, 04 Feb 2005 10:18:29 -0700jmfbahciv writes:
standard 360 might have do fetch protection (if feature was installed and active) on both start and end source locations (protection was on 2k boundary, so wouldn't involve more than two protection areas, start and end) and store protection check on target start and end locations (if store ptection feature was installed and active). If any of the store & fetch checks failed ... the instructure wasn't executed.
introduced with 370 was the long instructions, MVCL instruction specified origin address, origin count, target address and target count ... and possibly padding value (in the case that the origin count was less that the target count). The "long" instructions were interruptable ... but the address and length fields were all in registers ... and the long instructions were defined as executing incrementally and updating register values as they went along. In the case of interruption, the register values would indicate the current position. A long instruction could be interrupted for something like I/O or timer ... and the system then could be expected to restart the instruction (using the most current, updated register values). The register values could also be updated correctly for interrupt involving page fault, store protection, and/or fetch protection.
All 360 instructions pretested start and end address for store/fetch protection before starting the instruction. The 370 long instructions were defined as not pretesting start and end values because 1) lengths could be 24bit ... so large number of protected areas might be involved, 2) instructions were defined as incremental and interrruptable (so it was only necessary to test currently working area).
Note however, the initial 370 115/125 models shipped with a bug in the microcode of the long instructions. They implemented 360 praradigm preset for the long instructions ... and wouldn't execute the instruction if any violation appeared (so the registers appeared as if no incremenatal activity took place when the interrupt violation occurred). The definition of 370 long instructions was that incremental activity should have occurred up until the point that the violation occurred ... and then a violation interrupt would happen and the registers would point to the point of the violation.
In the morphing of cp67 to vm370 they got cute and decided to use MVCL long with zero source length, max. 16mbyte target length, and zero value for pad at boot time. This should clear all available real memory to zeros and interrupt when it ran out of memory (the register values at interrupt time would then indicate the size of real memory on the machine). I was installing vm370 on 370/125 for norwegian shipping company in their offices in downtown manhatten and couldn't get vm370 to boot. I finally had to hack the boot procedure and report that the MVCL instruction wasn't operating per the 370 architecture.
note that at the basic hardware metaphor, there was an awareness that both source and target areas have infrastructure determinable lengths.
detailed description of MVCL in 24-bit and 31-bit address modes
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/7.5.56?SHELF=EZ2HW125&DT=19970613131822
a more dettailed discussion of characteristics of interruptable
instructions
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/5.3.6?SHELF=EZ2HW125&DT=19970613131822#HDR05BH7
detailed description of MVCL from z/architecture giving 24-bit, 31-bit
and 64-bit address modes:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dz9zr003/7.5.90?DT=20040504121320
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: [Lit.] Buffer overruns Newsgroups: sci.crypt,alt.folklore.computers Date: Fri, 04 Feb 2005 10:23:41 -0700this may or may not be considered a reflection on views about the quality of c & c++ programming languages
from above ...
Java creator James Gosling this week called Microsoft's
decision to support C and C++ in the common language runtime in .NET
one of the "biggest and most offensive mistakes that they could have
made".
... snip ...
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: [Lit.] Buffer overruns Newsgroups: sci.crypt,alt.folklore.computers Date: Fri, 04 Feb 2005 10:42:42 -0700Paul Rubin <http://phr.cx@NOSPAM.invalid> writes:
one of the other most convoluted was luther woodrum's tree stuff that was adapted for stuff like sorting.
detailed description of the infrastructure and example use:
http://publibz.boulder.ibm.com:80/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/A.7
misc. past references to luther's instructions
https://www.garlic.com/~lynn/2001d.html#28 Very CISC Instuctions (Was: why the machine word size ...)
https://www.garlic.com/~lynn/2001h.html#73 Most complex instructions
https://www.garlic.com/~lynn/2001.html#2 A new "Remember when?" period happening right now
https://www.garlic.com/~lynn/2002d.html#18 Mainframers: Take back the light (spotlight, that is)
some past posts mentioning lincoln lab's SLT rpq
https://www.garlic.com/~lynn/98.html#20 Reviving the OS/360 thread (Questions about OS/360)
https://www.garlic.com/~lynn/2000d.html#47 Charging for time-share CPU time
https://www.garlic.com/~lynn/2001c.html#15 OS/360 (was LINUS for S/390)
https://www.garlic.com/~lynn/2001d.html#23 why the machine word size is in radix 8??
https://www.garlic.com/~lynn/2001h.html#71 IBM 9020 FAA/ATC Systems from 1960's
https://www.garlic.com/~lynn/2002f.html#54 WATFOR's Silver Anniversary
https://www.garlic.com/~lynn/2002h.html#87 Atomic operations redux
https://www.garlic.com/~lynn/2002.html#14 index searching
https://www.garlic.com/~lynn/2003m.html#35 SR 15,15 was: IEFBR14 Problems
https://www.garlic.com/~lynn/2004l.html#17 IBM 3090 : Was (and fek that) : Re: new computer kits
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: The mid-seventies SHARE survey Newsgroups: alt.folklore.computers Date: Fri, 04 Feb 2005 12:57:58 -0700blackhole_for_spam@the_skip.invalid writes:
this was a '60s era design where electronic memory was extremely expensive and it was not economically feasable to put it into each disk drive ... allowing local reading of disk surface track data whether or not there was dedicated transfer path back to the processor memory.
the methodology was to lock down and dedicate the data path from string switch, controller, and channel back to the processor main memory ... so that when the desired record had (finally) rotated under the head ... the path was available for transfer to main memory. Since there was a high degree of sharing of these data paths ... potentially across a large number of disks .... per device (& per operation), dedicated busy time could represent a significant system thruput bottleneck.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: [Lit.] Buffer overruns Newsgroups: sci.crypt,alt.folklore.computers Date: Fri, 04 Feb 2005 14:52:18 -0700Mack <macckone@a_nospamjunk123_ol.com> writes:
... or worse still in a copy operation where the string/source area may at least have some form of infrastructure determinable bounds (even tho it may have to be discovered during the processing of the operation) ... but frequently the typical target storage location for such copy operations tend to have no infrastructure determinable bounds ....
https://www.garlic.com/~lynn/2005c.html#33 [Lit.] Buffer overruns
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: [Lit.] Buffer overruns Newsgroups: sci.crypt,alt.folklore.computers Date: Fri, 04 Feb 2005 15:40:33 -0700Anne & Lynn Wheeler writes:
this was in the late '70s and one of those friday after work projects
(and lots of lubrication). we were looking for killer apps for the
non-online oriented population. we already had extensive email and
internal network connectivity i.e. the internal network was larger
than the arpanet/internet until approx. mid.-85 timeframe (and for the
crypto crowd ... since all links leaving pysical premises were
required to be encrypted ... the internal network was claimed to have
over half of all the link encryptors in the world ... and you don't
think it was a hassle back then getting link encryptors installed on
lines crossing national boundaries) ... misc. internal network
postings
https://www.garlic.com/~lynn/subnetwork.html#internalnet
minor specific post about internal network passing 1000 nodes not long
after the internet passed 256 nodes
https://www.garlic.com/~lynn/internet.htm#22
... in any case, 4-6hrs of friday after work libations and we come up with the idea of online telephone books (to go with email and online network) as another killer app. Now at the time, there was a proposal at the corporate level for $20m, dedicated hardware, and a dedicated staff of 20 people for a corporate online telephone book service.
by midnight, we had worked out that the basic criteria for the effort was
1) design and implementation of the application, 2) collection and formating of the data, and 3) deployment of production operation
had to be done in under two person weeks ... and 90th percentile respone under nominal heavy load had to be faster than manual lookup of paper phone directory on person's desk.
so we got an interactive application on record oriented mainframe with 500k or so records ... with approx 50 data records per 4k physical disk record. the trivial would be sort the file and do binary search ... the problem is that binary search would need an avg. of 12 physical record reads to get within the physical record that probably contains the target logical record. Given a heavily loaded system, that results in response that exceeds the original design criteria.
So binary search is good for sorted data w/o any knowledge of frequency of occurance. So name two-letter frequency analysis is performed and a table generated for the application. Now the application takes the first two letters of the search, looks it up in the starting letter name frequency table and uses that to calculate the initial radix partition probe. That tends to get the number of physical disk read probes down into the range of four (from 12 ... actually prossibly double that if you take into account various filesystem control structures).
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: [Lit.] Buffer overruns Newsgroups: sci.crypt,alt.folklore.computers Date: Fri, 04 Feb 2005 15:42:24 -0700Mack <macckone@a_nospamjunk123_ol.com> writes:
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: [Lit.] Buffer overruns Newsgroups: sci.crypt,alt.folklore.computers Date: Fri, 04 Feb 2005 16:23:41 -0700Randy Howard writes:
that hardly corresponds to the new buffer overflow attack book that i ran across earlier in the week (which is larger than the shellcoder's handbook). check your bookstore ... or do a search on someplace like amazon.com for buffer overflow attack (when i did it, three books came up).
it also doesn't hardly correspond to amd going to all the trouble of putting in hardware countermeasure (and windows shipping operating system software support for the hardware countermeasure) for buffer overflow exploits.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Oldest active information system Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Fri, 04 Feb 2005 18:02:23 -0700Shelley.Giles@ibm-main.lst (Giles, Shelley) writes:
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: [Lit.] Buffer overruns Newsgroups: sci.crypt,alt.folklore.computers Date: Sat, 05 Feb 2005 09:55:42 -0700Mack <macckone@a_nospamjunk123_ol.com> writes:
working on fire-grain locking for cp67 (he observed that majority of the requirements was for updating storage location ... which was somewhat different semantics that the TEST&SET instruction available on the 360/67). one of the tasks associated with getting compare&swap into the 370 architecture was coming up with a mnemonic that matched charlie's initials (CAS). Before availability, it was decided to do both compare&swap and compare-double-and-swap ... resulting in the actual assembler mnemonics being CS and CDS.
the other problem was that the owners of the architecture in POK said that it wasn't going to be possible to justify a new 370 instruction for purely SMP ... that a use/justification was needed that was only applicable to purely uniprocessor machine. That spawned the use of atomic instruction in multi-thread applications (like databases) that were enabled for interrupts ... and that after an interrupt control might be resumed with a different application thread. This gave rise to the compare&swap instruction programming notes in the 370 principles-of-operation ... that quickly found their way into the appendix.
360/370 had some number of RMW instructions that weren't defined as atomic; and, or, exclusive-or, etc. (they were non-interruptable, but weren't defined to be SMP-safe/atomic).
I had worked with charlie and reworked my dispatching, scheduling, resource management, paging, etc to be multiprocessor-sensitive (a lot of which I had originally done as an undergraduate). In the morph from cp67 to vm370, a lot of that was dropped.
Later, I got to put a lot of it back when they let me do the resource
manager:
https://www.garlic.com/~lynn/subtopic.html#fairshare
https://www.garlic.com/~lynn/subtopic.html#wsclock
At about the same time, I was also doing a SMP project that used
extensive microcode support for much of the infrastructure
https://www.garlic.com/~lynn/submain.html#bounce
however, VAMPS was canceled before it shipped. much of the design was adapted to a software only SMP implementation for ship as product.
a problem was that it was heavily dependent on kernel organization that was already part of the shipped resource manager.
the industry was going through a shift from free (& shipping source code) software to priced (and eventually OCO ... object-code-only). some application code had started being charged in the unbundling of 6/23/69 but kernel code was still free ... and we did full source code shipment as well as source code maintenance.
somewhat because of clone processors and other factors, there was a decision to start charging for kernel code. the resource manager was selected to be the guinea pig ... and i got to spend six months on and off with the business people working out the business practices for charged for kernel code. at that point the decision was that kernel code could be charged for that wasn't directly involved with hardware support (like resource management).
so the problem with the smp support was that it was directly involved with hardware support and therefor free. however, it was heavily dependent on code in the resource manager which was already shipping as priced software. the decision was finally made to move something like 80 percent of the code in the resource manager to the free kernel base (but continue to charge the same price for the reduced code resource manager).
lots of other SMP posts:
https://www.garlic.com/~lynn/subtopic.html#smp
370 principles of operation (warning 31mbytes)
http://www.bitsavers.org/pdf/ibm/370/princOps/GA22-7000-4_370_Principles_Of_Operation_Sep75.pdf
much of the compare&swap programming notes were in the appendix (pg. 310-314 in the above).
more recently the PLO (perform locked operation) instruction has been introduced.
compare and swap
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/7.5.22?SHELF=EZ2HW125&DT=19970613131822
compare double and swap
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/7.5.23?SHELF=EZ2HW125&DT=19970613131822
more recent perform locked operation
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/7.5.69?SHELF=EZ2HW125&DT=19970613131822
test and set (still around from 360 days)
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/7.5.92?SHELF=EZ2HW125&DT=19970613131822
appendix A.6 Multiprogramming (multi-thread) and Multiprocessing
Examples
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/A.6?SHELF=EZ2HW125&DT=19970613131822
appendix A.6.1 Example of a program failure using OR immediate
(non-atomic RMW)
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/A.6.1?SHELF=EZ2HW125&DT=19970613131822
the rest are bits and pieces from the original 370 POP programming notes (used to justify getting compare&swap in the 370 hardware)
appendix A.6.2 Conditional Swapping Instructions (CS, CDS)
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/A.6.2?SHELF=EZ2HW125&DT=19970613131822
appendix A.6.3 Bypassing Post and Wait
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/A.6.3?SHELF=EZ2HW125&DT=19970613131822
appendix A.6.4 Lock/Unlock
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/A.6.4?SHELF=EZ2HW125&DT=19970613131822
appendix A.6.5 Free-Pool Manipulation
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/A.6.5?SHELF=EZ2HW125&DT=19970613131822
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: History of performance counters Newsgroups: comp.arch,alt.folklore.computers Date: Sat, 05 Feb 2005 10:30:33 -0700"del cecchi" writes:
one of the most difficult challenges was convincing various site security people that softcopy of the plant telephone directory didn't have to be treated as confidential ... it could be considered simply "internal use only" (as was the paper copy of the same).
once the security people at one plant site was convinced ... we could use that fact in arguments with other plant site security people.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: [Lit.] Buffer overruns Newsgroups: sci.crypt,alt.folklore.computers Date: Sat, 05 Feb 2005 12:36:07 -0700Brian Inglis writes:
in the 70s, we got to shoot an email network scripting exploit ... and basically came back with the recommendation that automatic command scripting of network arrived files will need to be prevented. there has been a whole class of viruses starting (at least) in the late 90s having to do with automatic scripting of network arrived files (visual basic, javascript, java, etc). some number of this class of viruses tend to be application related and whether or not they support automatic scripting of network arrived files.
note however, there are parts of the mac environment that have been susceptible to buffer overflow attacks ... and it is specifically these that the AMD hardware is a countermeasure for.
the issue with the no-execute paradigm is that the c language environments have been thick with buffer overflow vulnerability exploits ... dating back to at least the morris/internet worm. It isn't a fix for buffer overflow software bug ... using a biological analogy ... buffer overflow vulnerability is an infection vector. the no-execute paradigm is trying to keep the patient alive (as opposed to eradicating the bug).
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: History of performance counters Newsgroups: comp.arch,alt.folklore.computers Date: Sat, 05 Feb 2005 10:39:42 -0700Lee Witten writes:
we also had some confrontations with them about the available of "games" on the system. we asserted that it would be better to have single copy of games in public area on the system ... then everybody having their own individual disguised copy ... and furthermore they were quite educations.
I had gotten a very early copy of Fortran source from Tymshare that they had ported from stanford sail to their vm370/cms timesharing service ... and I was making it available inside the company (I would also send the source to anybody that could proove they made all points). I was asserting that it was a good exposure to some more interesting interactive human factors (than most of them had been exposed to with online systems up until then). At one point, the executives at STL/bldg.90 claimed that 1/3rd of all computer use appeared to be consumed playing adventure ... and they gave notice of 24hr grace period and after that no 1st shift playing of adventure would be tolerated.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: History of performance counters Newsgroups: comp.arch,alt.folklore.computers Date: Sat, 05 Feb 2005 10:55:38 -0700note, one of the wording changes was from "Business Use Only" ... we pointed out that it was management discretion that people may do things like talk to their spouse or children on their desk phone during the course of the day ... if it didn't impact business operations. The analogy that computers shouldn't be treated any differently than any other business facility.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: [Lit.] Buffer overruns Newsgroups: sci.crypt,alt.folklore.computers Date: Sun, 06 Feb 2005 08:43:45 -0700"Douglas A. Gwyn" writes:
one of the things normally required for most ABC implementations are infrastructure determinable storage lengths that can be used as part of bounds specification. for instance the prevalent string paradigm doesn't have a length value for an ABC operation that is able to determine whether an arbitrary byte location is on one side of the string bound or the other side of the string bound ... without scanning the string itself for the data-pattern bound characteristic.
Most ABC operations tend to have calculatable storage address bound based on a infrastructure providing either explicit start/length or start/end value pairs .... as opposed to infrastructure bounds semantics based on arbitrary data pattern contained somewhere in the storage area (or no available infrstructure determinal bound pair value at all).
in the 370 MVCL instruction both the source and target origins and lengths are specified separately (along with optional fill character to be used in situation where the source length is less than the target length). This would be considered a ABC semantics that is part of the machine instruction specification.
One possible difference between most higher level programming languages and most machine programming languages ... is that in the higher level programming languages, the actual machine instructions don't tend to be known by the programmer ... and there can be different instructions generated/executed with ABC active or not active. However, other ABC paradigms are possible ... like with the 370 MVCL instruction where the bounds specification are actually part of the instruction semantics. Other ABC paradigms are at a more gross level ... the use of store protect (and virtual address space mapping) to preclude programs from wild stores outside their security domain (common countermeasure preventing arbitrary applications from overlaying kernel storage areas).
Now, many hardware architectures have had various kinds of storage protection mechanisms for decades ... which doesn't correct program behavior any more than fine-grain ABC operations correct program behavior. However, it has become recognized that various kinds of application mis-behavior countermeasures are an extremely useful characteristic.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: [Lit.] Buffer overruns Newsgroups: sci.crypt,alt.folklore.computers Date: Sun, 06 Feb 2005 09:31:58 -0700Friday, FTC released latest statistics on identity theft. As part of co-author of new ANSI (and being put forward for ISO) financial privacy (PIA) standard ... I started a merged privacy taxonomy and glossary to go along with the others
one of the things that was related to privacy was a study that found the primary motivations (driving factors) for privacy regulatory and legislative activity were 1) denial of service (by institutions/govs) and 2) identity theft.
so i'm also getting suggestions about beefing up the merged security taxonomy and glossary with more identity theft related stuff. some number of sites mention that terms around identity theft are inconsistant and vague and i'm being forced to pull terms and definitions out of the text of documents that I run across.
Yesterday, I added a couple minor things on identity theft, account hijacking, etc, extracted from the body of an FTC overview document.
However, in the process, I ran across a small cybercrime glossary on
the federal judiciary center site that consisted of the following
(note that buffer overflow is not only a software bug but is also
included as part of cybercrime):
back door
buffer overflow
cracker
dumpster diving
hacker
insider
logic bomb
malicious applets
password cracker
scan
script bunny
sniffer
social engineering
spoofing
trojan horse
virus
war dialing
worm
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: [Lit.] Buffer overruns Newsgroups: sci.crypt,alt.folklore.computers Date: Sun, 06 Feb 2005 11:00:08 -0700infobahn writes:
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: [Lit.] Buffer overruns Newsgroups: sci.crypt,alt.folklore.computers Date: Sun, 06 Feb 2005 14:27:36 -0700infobahn writes:
another jargon file that may be of some interest was done
originally by mike ... and a version can be found at
http://www.212.net/business/jargon.htm
and a totally unrelated recent (mike) reference (and a PL where it is
difficult to cause buffer overflows):
http://www.osnews.com/story.php?news_id=8915
http://www.oorexx.org/
which then leads to
http://www.rexxla.org/
ansi standards
http://www.rexxla.org/Standards/standards.html
way back when i was redoing the system fault analysis program (previously mentioned in this thread, original was something like 60klocs of assembler), i started out by saying that i would redo it in rex (before name change to rexx and released as product), make the rex version run ten times faster (than the assembler version) and have ten times the functions (and initial version, start to finish/release in under six person weeks).
earlier posting in this thread
https://www.garlic.com/~lynn/2004q.html#84 [Lit.] Buffer overruns
random earlier postings
https://www.garlic.com/~lynn/submain.html#dumprx
two related agendas was to 1) demonstrate power of rex ... and that it wasn't just another command scripting language like EXEC and EXEC2 ... and since this was getting into the transition period from full-source distribution and maintenance to object-code-only ... choose something (that at the time) would absolutely require source distribution (assuming that they would ever decide to ship it to customers).
in another lifetime i went thru a period of appending random selected
http://www.212.net/business/jargon.htm
entries to the end of email ... and then transitioned to yow/zippy.
I then tried to convert yow to support the jargon file. turns out that
yow has a random number issue. zippy/yow file was around 30k bytes,
and yow was using signed halfword random number (2**15-1) to select a
byte location in the file ... and then do some twiddling to find a
record (string) boundary. you could use yow on any file ... but it
wouldn't work as might be expected with a file over 400kbytes.
Words of wisdom from Zippy:
.. this must be what it's like to be a COLLEGE GRADUATE!!
and
IBM Jargon:
MIP envy - n. The term, coined by Jim Gray in 1980, that began the
Tandem Memos (q.v.). MIP envy is the coveting of other's facilities -
not just the CPU power available to them, but also the languages,
editors, debuggers, mail systems and networks. MIP envy is a term
every programmer will understand, being another expression of the
proverb The grass is always greener on the other side of the fence.
... and of course, i'm the one that has taken the blame for doing
tandem memos (datamation even said so).
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: [Lit.] Buffer overruns Newsgroups: sci.crypt,alt.folklore.computers Date: Sun, 06 Feb 2005 15:44:53 -0700Mack <macckone@a_nospamjunk123_ol.com> writes:
i made the rounds of the usual vendors that sell stuff that involves tcp/ip and/or connecting to the internet ... suggesting that maybe they do something to address the problem; nobody was interested.
almost exactly a year later a similar symptom hit a service provider in manhatten (it may have possibly even been aug. 17th of the following year) and all of a sudden it was in the press ... and now you saw the usual players telling the press about how fast they were addressing the problem.
now that particular service provider (that made the press) ... i believe may be the same one that was recently in the press with the domain name hijacking problem.
some recent domain name hijacking refs:
http://www.theregister.co.uk/2005/01/17/panix_domain_hijack/
http://news.zdnet.co.uk/internet/security/0,39020375,39184371,00.htm
http://www.securityfocus.com/news/10311
http://www.ebcvg.com/news.php?id=4511
http://www.net4nowt.com/isp_news/news_article.asp?News_ID=2615
http://www.technewsworld.com/story/ebiz/panix-domain-name-hijack-39791.html
http://www.thestandard.com/internetnews/000845.php
some random past posts mentioning domain name hijacking
https://www.garlic.com/~lynn/aadsm4.htm#3 Public Key Infrastructure: An Artifact...
https://www.garlic.com/~lynn/aadsmore.htm#client1 Client-side revocation checking capability
https://www.garlic.com/~lynn/aadsmore.htm#client3 Client-side revocation checking capability
https://www.garlic.com/~lynn/aadsmore.htm#client4 Client-side revocation checking capability
https://www.garlic.com/~lynn/aadsmore.htm#pkiart Public Key Infrastructure: An Artifact...
https://www.garlic.com/~lynn/aadsmore.htm#pkiart2 Public Key Infrastructure: An Artifact...
https://www.garlic.com/~lynn/aepay4.htm#dnsinteg2 Domain Name integrity problem
https://www.garlic.com/~lynn/aadsm8.htm#softpki2 Software for PKI
https://www.garlic.com/~lynn/aadsm8.htm#softpki16 DNSSEC (RE: Software for PKI)
https://www.garlic.com/~lynn/aadsm9.htm#cfppki5 CFP: PKI research workshop
https://www.garlic.com/~lynn/aadsm10.htm#cfppki20 CFP: PKI research workshop
https://www.garlic.com/~lynn/aepay11.htm#37 Who's afraid of Mallory Wolf?
https://www.garlic.com/~lynn/aadsm14.htm#1 Who's afraid of Mallory Wolf?
https://www.garlic.com/~lynn/aadsm15.htm#28 SSL, client certs, and MITM (was WYTM?)
https://www.garlic.com/~lynn/aadsm17.htm#60 Using crypto against Phishing, Spoofing and Spamming
https://www.garlic.com/~lynn/aadsm18.htm#17 should you trust CAs? (Re: dual-use digital signature vulnerability)
https://www.garlic.com/~lynn/2000e.html#40 Why trust root CAs ?
https://www.garlic.com/~lynn/2000e.html#47 Why trust root CAs ?
https://www.garlic.com/~lynn/2001d.html#41 solicit advice on purchase of digital certificate
https://www.garlic.com/~lynn/2001e.html#39 Can I create my own SSL key?
https://www.garlic.com/~lynn/2001e.html#40 Can I create my own SSL key?
https://www.garlic.com/~lynn/2001g.html#19 Root certificates
https://www.garlic.com/~lynn/2001l.html#26 voice encryption box (STU-III for the masses)
https://www.garlic.com/~lynn/2001n.html#57 Certificate Authentication Issues in IE and Verisign
https://www.garlic.com/~lynn/2001n.html#73 A PKI question and an answer
https://www.garlic.com/~lynn/2004b.html#39 SSL certificates
https://www.garlic.com/~lynn/2004h.html#28 Convince me that SSL certificates are not a big scam
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: [Lit.] Buffer overruns Newsgroups: sci.crypt Date: Mon, 07 Feb 2005 07:20:53 -0700"Douglas A. Gwyn" writes:
the implication is that length/bound values were undeterminable to the infrastructure (in c language environment) and the infrastructure was therefor dependent on the programmer always providing the correct values. ABC tends to require that the infrastructure have access to determinable length/bounds values in order to implement ABC bounds operation (but as you pointed out, typical c language environments don't have determinable length values for dynamic buffers and is dependent on programmers always correctly specifying the value).
so you either have infrastructure determinable length values or you have progammer specified length values (where the programmer always specifies the correct value).
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: [Lit.] Buffer overruns Newsgroups: sci.crypt,alt.folklore.computers Date: Mon, 07 Feb 2005 08:26:05 -0700jmfbahciv writes:
some of my (cp67) paging, scheduling and dispatching code wasn't easy to understand ... some things would be happening for no obvious reason (some of my code optimization to do some very complex things in zero lines of code ... by carefully organization of various other kernel code to achieve the desired objective w/o any obvious, explicit code making it happen).
for instance, i had come up with global LRU and clock page replacement algorithms as an undergraduate. This was at a time when the big thing in the literature was local LRU page replacement. At the time, most of the algorithms were attempting to get as close as possible to true-LRU (except for stuff like belady's opt ... which required future knowledge of what the program was going to do). I then did a slight-of-hand modification to global LRU/clock implementation that for all intents and purposes still looked like global LRU/clock ... but had this unsettling condition of being better than strict-LRU (shown in simulations using detailed instruction traces and implementing strict-LRU).
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: 12-2-9 REP & 47F0 Newsgroups: alt.folklore.computers Date: Mon, 07 Feb 2005 11:58:26 -0700paul c writes:
they gave me manuals and access to the machine ... and a 1401 program (MPIO) that did unitrecord<->tape front end for 709. I was suppose to duplicate the MPIO function on 360/30 in 360 assembler (still acting as ur<->tape front end for 709).
i designed my own interrupt handlers, device drivers, memory management, task monitor, commands, etc.
towards the end it was about 2000 cards that i would assemble under PCP ... taking about 30 minutes elapsed time. I would patch by (visually) reading the hex (punch holes) in the 12-2-9 TXT cards ... duplicating the card on 026/029 and multi-punching the new hex values producing a new replacement TXT card. I got so that i could almost read the hex values from the punch holes as fast as straight character.
past 12-2-9 postings:
https://www.garlic.com/~lynn/93.html#17 unit record & other controllers
https://www.garlic.com/~lynn/95.html#4 1401 overlap instructions
https://www.garlic.com/~lynn/2001.html#8 finding object decks with multiple entry points
https://www.garlic.com/~lynn/2001.html#14 IBM Model Numbers (was: First video terminal?)
https://www.garlic.com/~lynn/2001.html#60 Text (was: Review of Steve McConnell's AFTER THE GOLD RUSH)
https://www.garlic.com/~lynn/2001m.html#45 Commenting style (was: Call for folklore)
https://www.garlic.com/~lynn/2002h.html#1 DISK PL/I Program
https://www.garlic.com/~lynn/2004h.html#17 Google loves "e"
https://www.garlic.com/~lynn/2004p.html#24 Systems software versus applications software definitions
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: [Lit.] Buffer overruns Newsgroups: alt.folklore.computers Date: Tue, 08 Feb 2005 00:07:20 -0700how 'bout a similar thread from 2002 x-posted to sci.crypt and a.f.c?
a couple past threads mentioning kildall
https://www.garlic.com/~lynn/2001b.html#52 Kildall "flying" (was Re: First OS?)
https://www.garlic.com/~lynn/2001b.html#53 Kildall "flying" (was Re: First OS?)
https://www.garlic.com/~lynn/2001b.html#60 monterey's place in computing was: Kildall "flying" (was Re: First OS?)
https://www.garlic.com/~lynn/2004e.html#38 [REALLY OT!] Overuse of symbolic constants
https://www.garlic.com/~lynn/2004h.html#40 Which Monitor Would You Pick??????
note that above posting on "overuse of symbolic constants" has some quotes from some books/articles ... including claim that cp/m name was derived from cp67/cms having been used at the npg school in 72; similar quotes i repeated in the "which monitor would you pick" posting.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: intel's Vanderpool and virtualization in general Newsgroups: comp.arch,alt.folklore.computers Date: Tue, 08 Feb 2005 17:43:58 -0700"Eric P." writes:
the big monolithic operating systems were sometimes having trouble focusing on specific issues ... in some respects because there is no clearly deliniated architecture and feature/function requirements between the various components.
cp/67 and virtual machine architecture ... provided a microkernel architecture ... with relatively clearly deliniated areas of responsibility for various components. because cp67 had clearly delineated interfaces, responsibilities and duties ... it provided quite stringent security partitioning ... something as a side-effect.
in the late 60s, you started seeing cp67 based time-sharing service
bureaus ... deliverying online personal computing in highly secure
manner to places like the financial and gov. market segments. this
continued with the morphing of cp67 to vm370 supporting the 370
computer line. virtual machine partitioning providing security
partitioing for personal computing delivery platform (that was hard to
find in other infrastructures).
https://www.garlic.com/~lynn/submain.html#timeshare
the other thing that i assert was that because you could run your environment on the bare metal and under cp67 ... focus was naturally drawn to cp67 pathlengths (how many operating systems do the users focus on the performance difference between running their application with and w/o the operating system ... the traditional answer has been that is just part of the cost of having an operating system).
anyway as a result ... i got to rewrite large portions of the (micro-)kernel code ... in some cases improving pathlength performance by a factor of 100. somewhat enabling this ... was the microkernel implementation made it a lot easier to be able to go thru every line of code and decide what needed rewriting and what didn't. I also got to invent fair share scheduling, new page replacement algorithms, disk arm scheduling stuff ... and all sorts of other interesting stuff ... and it would get picked up and shipped in the standard product.
the personal computing paradigm provided by the virtual machine
metaphor also heavily contributed to the invention of various kinds of
interactive related stuff. GML (precursor to sgml, html, xml, and
the markup language genre) was invented in that environment at the
science center in 1969.
https://www.garlic.com/~lynn/submain.html#sgml
the internal network technology was also developed for this platform
at the science center; the internal network for almost the whole period
until sometime mid-85 was larger than arpanet/internet
https://www.garlic.com/~lynn/subnetwork.html#internalnet
possible one of the largest time-sharing service delivery operations
was also based on this platform was an internal operation called HONE
... it supported world-wide sales, marketing and filed people. In the
early days as HONE was preducing clones around the world ... I got
to hand deliver some number of the installations ... and supporting
hone was one of my hobbies for something like 15 years
https://www.garlic.com/~lynn/subtopic.html#hone
the original sql/rdbms (system/r) database was developed at sjr on
this platform ... and then there was technology transfer from sjr to
endicott for product sql/ds (also on this platform)
https://www.garlic.com/~lynn/submain.html#systemr
later as you go into the 80s, you start seeing mainframes incorporating more and more virtualization related function as part of the native hardware until you eventually arrive with the whole LPAR paradigm ... it is possible to do a subset of virtual machine function ... and split the machine into maybe 10-15 partitions. It uses dedicated real storage ... and base/bound technology for real machine storage addresses ... but otherwise allows shared used of processor resources (including options like dedicated specific processors to specific LPARs). Part of this is allowed the same real hardware to support production machine operations concurrent with test operations. Another part was allowing a business operation to partition things into smaller dedicated pieces for more focused manageability.
Note that within an LPAR, it was still possible to run the virtual machine operating system ... which in turn allowed much finer grain partitioning. one such example was that a couple years ago ... on a small, resource restricted LPAR they ran a test with the virtual machine operation system ... where they in turn created 42,000 separate LINUX virtual machines.
a couple relatively recent postings mentioning LPAR:
https://www.garlic.com/~lynn/2004q.html#18 PR/SM Dynamic Time Slice calculation
https://www.garlic.com/~lynn/2004q.html#72 IUCV in VM/CMS
https://www.garlic.com/~lynn/2005b.html#5 Relocating application architecture and compiler support
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Thou shalt have no other gods before the ANSI C standard Newsgroups: sci.crypt,alt.folklore.computers Date: Tue, 08 Feb 2005 19:07:52 -0700paul c writes:
here is picutre of 2741 looking somewhat down from the top.
http://www.columbia.edu/cu/computinghistory/2741.html
(with respect to the above ... i have a 2741 apl golfball sitting on top my display). i started long history of pretty continuous home online access with a 3rd party "portable" 2741 (two 40lb suitcases) in mar. 1970 ... but soon got a "real" 2741 at home which i had into the late '70s.
when i was undergraduate ... i came up with this neat terminal identification sequence that could handle tty, 2741, and 1052s ... the mainframe terminal controller actually had a command that you could dynamically assign the terminal-type specific line-scanner to any port. so i had this magic code that ran thru a bunch of sequences to figure out the terminal type w/o having to pre-specify it. it worked when the terminals were hard-wired connected to specific ports ... but i also wanted to have a single phone pool with single dial-in number for all terminals. that was when the local hardware people pointed out that they had taken a short-cut with the terminal controller ... and while you could assign an arbitrary line-scanner to any port ... specific speed oscillators were hardwired to ports ... aka a specific port was hardwired for either 110 or 134.5 ... even tho on could use tty, 2741, and/or 1052 linescanner on every port.
so that somewhat kicked off a project to reverse engineer the ibm channel interface and build own channel interface card to put in interdata/3 and program the interdata/3 to emulate an ibm terminal controller (the interdata/3 had software linescanner and was programmed to do automatic line speed detect).
somebody wrote this up as helping spawn the plugged compatable
controller bussines ... and i'm getting blamed instigating it.
https://www.garlic.com/~lynn/submain.html#360pcm
later ... when the future system effort was started ... some amount
of the documentation says that it was targeted as having a much
higher degree of box integration as a countermeasure to the plug
compatible controller business
https://www.garlic.com/~lynn/submain.html#futuresys
while FS was eventually canceled ... there is some stories that at least some motivation for cloan mainframe processors were engineers that wanted to keep on producting 360/370 machines ... while the corporation was saying that they were going to have as bigger transition from 360 to FS architecture than there had been from pre-360s to 360 architecture.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Thou shalt have no other gods before the ANSI C standard Newsgroups: sci.crypt,alt.folklore.computers Date: Tue, 08 Feb 2005 19:17:00 -0700and to bring it slightly back to buffer overflow ... the original cp67 had 2741 and 1052 support ... but the university had these ttys ... so the modifications that eventually led to building our own controller, helping start the pcm controller clone business, which is described as primary motivation behind FS ... was my adding tty support to the base cp67 (before going off and doing all these other wild & wonderful stuff).
so because of tty terminal limination ... i used some one-byte operations associated with input length calculations. this was some of the stuff added to the base product and shipped.
as previously mention ... somebody at mit modified some cp67 they were running (totally different from the science center system on 4th flr, 545 tech sq), i believe to support some new ascii/tty device that somebody had down at harvard. they change the maximum length values to something like 1200 ... but failed to change the one byte operations ... which led to the repeated system crashes.
recent post on the subject
https://www.garlic.com/~lynn/2005b.html#30 [Lit.] Buffer overruns
story of what happened appears part way down this page
https://www.multicians.org/thvv/360-67.html
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: intel's Vanderpool and virtualization in general Newsgroups: comp.arch,alt.folklore.computers Date: Wed, 09 Feb 2005 10:04:40 -0700nmm1@cus.cam.ac.uk (Nick Maclaren) writes:
so this was one of the first major production uses of the internal network software ... also developed at the science center.
after there was cp67 kernel that had the support for 370 virtual machines, then another set of modifications were made to cp67 ... so that it the kernel would conform to 370 relocate tables and instructions (rather than 360).
now science center had a problem ... it was providing semi-open time-sharing access to non-corporate employees (mit, bu, harvard, etc students). it was also hosting some extended APL access by people from corporate hdqtrs that had loaded the most sensitive and most highly classified corporate data on the machine for doing business modeling and what-ifs (in the era, apl was used for a lot of the stuff that spreadsheets are now used for).
in any case there was an issue if the cp67 kernel that provided
virtual 370 machines was run on the bare hardware ... there might be
some of the area students stumble across the features (and they were
trying to fairly tightly control the secret of virtual memory for
370). in any case,
cp67-l kernel was run on bare hardware providing general computing
access
cp67-h kernel was run in a 360/67 virtual machine and it provided
370 virtual machines
cp67-i kernel was run in a 370 (virtual memory) virtual machine
cms was run in a 370 virtual machine
so that has been running for something like a year. endicott engineers
finally claim that they have an 370/145 with engineering changes to
support virtual memory and it is ready for some testing.
some people go to endicott and install a cp67-i kernel and attempt to boot ... and it fails. so some amount of investigation ... and it turns out that the kernel is correct ... but the engineers had reversed the implementation of the "B2" opcodes for PTLB (purge lookaside table) and RRB (reset reference bit). so some quick patches in a couple places ... and the kernel boots and runs fine. also software designed to the architecture spec runs correctly in virtual machines ... since the virtual machine emulation of the "B2" opcodes conform to the official architecture ... it is only the real kernel use of the functions that has been changed to conform to the real machine.
current description of PTLB
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/10.30?SHELF=EZ2HW125&DT=19970613131822
you have to settle for current description of RRB-extended:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/10.31?SHELF=EZ2HW125&DT=19970613131822
part of the difference was that 370 supported both 2kbyte pages and 4kbyte pages ... so RRB operated on 2k blocks of storage. support for 2k byte pages has since been dropped.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: intel's Vanderpool and virtualization in general Newsgroups: comp.arch Date: Wed, 09 Feb 2005 17:00:50 -0700Andrew Reilly <andrew-newspost@areilly.bpc-users.org> writes:
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: comp.arch thread "intel's vanderpool and virtualization in general" ,,, fyi Newsgroups: bit.listserv.vmesa-l Date: Thu, 10 Feb 2005 08:16:58 -0700some recent posts in comp.arch vanderpool thread
vanderpool webpage
http://www.intel.com/technology/computing/vptech/
press release
http://www.intel.com/pressroom/archive/releases/20050120comp.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Thou shalt have no other gods before the ANSI C standard Newsgroups: sci.crypt,alt.folklore.computers Date: Thu, 10 Feb 2005 08:09:21 -0700Andrew Swallow writes:
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: intel's Vanderpool and virtualization in general Newsgroups: comp.arch Date: Thu, 10 Feb 2005 09:48:12 -0700"mike" writes:
1) using simplified interface for improved (and checkable) partitioning and isolation (where things are really totally unrelated) and
2) using simplified interface for improved (and checkable) partitioning and isolation (where things may require interaction).
in the later case, MVS sort of backed into this when they started hitting the 16mbyte addressing limit and extensive dependance on pointer-passing paradigm.
OS/VS2-SVS was essentially the real stoarge MVT kernel laid out in a (single) 16mbyte virtual address space. The transition to OS/VS2-MVS involved giving each application their own address space ... but with the kernel image occupying 8mbytes of each 16mbyte virtual address space. This moved some number of "services" that weren't in the kernel into different virtual address spaces than the applications for which they were suppose to provide services for.
This gave rise to dual-address support with the 3033 (allowing the "service" to use pointers that pointed into an application address space) ... however, you still needed to do a kernel call to switch from the application address space to the service address space.
Wtih the evolution of architecture, there was also introduction of stuff like "access registers" and program-call.
Basically program-call was a branch-and-link type library call ... but was supported by a kernel-based access/privileges table (analogous to kernel-based virtual memory tables that support virtual address spaces). Basically the program-call instruction could reference the access/privilege table (in mannter analogous to virtual addresses being resolved by accessing kernel-based virtual memory tables) to resolve the program-call.
The hardware then handles both virtual address space and context switching w/o requiring kernel processing via kernel call (making program-call almost as fast as a branch-and-link operation).
So the claim was that the 3033 with dual-address space support started to see more TLB misses because of the increase in the total different virtual address spaces ... aka TLB entries were virtual address space associative, with a STO-stack ... where "STO" equates to unique virtual address space. Transition to dual-address space support had a hit on the size of the STO-stack needed (because of the increase in unique virtual address spaces needed to perform an operation).
So with program-call, it had eliminated the kernel call for context and address space switch. The total cache-line hit was about the same as with the straight branch-and-link subroutine call paradigm (with everything within the same address space) ... since the amount of code was effectively the same (modulo that the program-call instruction had to reference the kernel access/privilege table). The number of the TLB entries were about the same since the amount of code was still about the same. The biggest hit was on the STO-stack table (number of concurrent different/unique virtual address spaces that TLB could keep track of).
program-call description
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/10.26?SHELF=EZ2HW125&DT=19970613131822
access register discussion
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/E.1.1?SHELF=EZ2HW125&DT=19970613131822
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Is the solution FBA was Re: FW: Looking for Disk Calc program/Exec Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Thu, 10 Feb 2005 12:35:36 -0700cfmtech@ibm-main.lst (Clark F. Morris, Jr.) writes:
for some drift ... random past ckd (& fba) posts
https://www.garlic.com/~lynn/submain.html#dasd
and for even more drift ... tales from the disk engineer and product
test labs (bldgs. 14&15 ... although for awhile disk engineering move
to an offsite "bldg 86" while 14 was getting its seismic retrofit).
https://www.garlic.com/~lynn/subtopic.html#disk
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Thou shalt have no other gods before the ANSI C standard Newsgroups: sci.crypt,alt.folklore.computers Date: Thu, 10 Feb 2005 16:03:29 -0700"Charlie Gibbs" writes:
for doing both terminal type identification and terminal speed determination ... our first transfer of data to mainframe memory appeared to be totally garbeled.
terms out that the line-scanners in the official terminal controller placed the leading arriving bit in the low-order bit position (in a byte) ... so that ascii data was arriving in mainframe memory bit-reversed within a byte. The official ascii terminal translate tables were then handling the bit-reversed bytes when doing ascii<->ebcdic translation (both on incoming as well on outgoing).
we initially overlooked that when first transfer of incoming ascii data into mainframe memory ... placing leading bit in high-order bit position (within a byte). we quickly diagnosed the problem and fixed the interdata/3 so that it transferred the ascii bytes to mainframe memory in bit-reversed format.
now much later ... mainframes would have two kinds of ascii translate tables ... one for use with terminal controllers where the line-scanners did bit-reversal of ascii bytes ... and another for use with various kinds of things like LAN interfaces that transferred bytes in non-bit-reversed byte format (regardless of the coding type).
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: re: looking to buy a working DX box Newsgroups: bit.listserv.vmesa-l Date: Thu, 10 Feb 2005 23:23:13 -0700mike walter wrote:
now all i have is the front panel from one. i did forward the message to one of the engineers that use to build them.
anybody notice that the founder of network systems died last month
(thornton of cdc fame).
http://twincities.bizjournals.com/twincities/stories/2005/01/10/daily46.html
random topic drift ... i had done rfc 1044 support for mainframe
tcp/ip as well as some number of other nsc device drivers:
https://www.garlic.com/~lynn/subnetwork.html#1044
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: intel's Vanderpool and virtualization in general Newsgroups: comp.arch,alt.folklore.computers Date: Fri, 11 Feb 2005 10:47:53 -0700nmm1@cus.cam.ac.uk (Nick Maclaren) writes:
going back to OS/360 they have a really heavy weight dispatching unit with task control block (TCB). lots of online and transactions systems would create a large subsystem under OS/360 and then implement their own internal dispatching & scheduling (to avoid the really heavy weight operation of the main dispatcher); things like cics, ims, atm transaction stuff, etc.
somewhere along the way, SRBs were created for MVS (basically a light weight kernel threaded mechanism ... my vague recollection was that STL & IMS group were heavily involved in the SRB stuff).
however, the mainframe hardware program call stuff is a mechanism that is analogous to an application making an internal call to a subroutine library ... that just happens to be in another virtual address space (and doesn't require kernel checking about resource allocation, etc). The execution of the subroutine library then has (slightly elevated) privileges to address back into the calling application's address space.
various past gnosis/keykos postings.
https://www.garlic.com/~lynn/2000g.html#22 No more innovation? Get serious
https://www.garlic.com/~lynn/2001b.html#73 7090 vs. 7094 etc.
https://www.garlic.com/~lynn/2001g.html#33 Did AT&T offer Unix to Digital Equipment in the 70s?
https://www.garlic.com/~lynn/2001g.html#35 Did AT&T offer Unix to Digital Equipment in the 70s?
https://www.garlic.com/~lynn/2001n.html#10 TSS/360
https://www.garlic.com/~lynn/2002f.html#59 Blade architectures
https://www.garlic.com/~lynn/2002g.html#0 Blade architectures
https://www.garlic.com/~lynn/2002g.html#4 markup vs wysiwyg (was: Re: learning how to use a computer)
https://www.garlic.com/~lynn/2002h.html#43 IBM doing anything for 50th Anniv?
https://www.garlic.com/~lynn/2002i.html#63 Hercules and System/390 - do we need it?
https://www.garlic.com/~lynn/2002j.html#75 30th b'day
https://www.garlic.com/~lynn/2003g.html#18 Multiple layers of virtual address translation
https://www.garlic.com/~lynn/2003h.html#41 Segments, capabilities, buffer overrun attacks
https://www.garlic.com/~lynn/2003i.html#15 two pi, four phase, 370 clone
https://www.garlic.com/~lynn/2003j.html#20 A Dark Day
https://www.garlic.com/~lynn/2003k.html#50 Slashdot: O'Reilly On The Importance Of The Mainframe Heritage
https://www.garlic.com/~lynn/2003l.html#19 Secure OS Thoughts
https://www.garlic.com/~lynn/2003l.html#22 Secure OS Thoughts
https://www.garlic.com/~lynn/2003l.html#26 Secure OS Thoughts
https://www.garlic.com/~lynn/2003m.html#24 Intel iAPX 432
https://www.garlic.com/~lynn/2003m.html#54 Thoughts on Utility Computing?
https://www.garlic.com/~lynn/2004c.html#4 OS Partitioning and security
https://www.garlic.com/~lynn/2004e.html#27 NSF interest in Multics security
https://www.garlic.com/~lynn/2004m.html#29 Shipwrecks
https://www.garlic.com/~lynn/2004m.html#49 EAL5
https://www.garlic.com/~lynn/2004n.html#41 Multi-processor timing issue
https://www.garlic.com/~lynn/2004o.html#33 Integer types for 128-bit addressing
https://www.garlic.com/~lynn/2004p.html#23 Systems software versus applications software definitions
https://www.garlic.com/~lynn/2005.html#7 How do you say "gnus"?
https://www.garlic.com/~lynn/2005b.html#6 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005b.html#7 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005b.html#12 [Lit.] Buffer overruns
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Thou shalt have no other gods before the ANSI C standard Newsgroups: sci.crypt,alt.folklore.computers Date: Fri, 11 Feb 2005 10:50:24 -0700"Hank Oredson" writes:
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: intel's Vanderpool and virtualization in general Newsgroups: comp.arch,alt.folklore.computers Date: Fri, 11 Feb 2005 12:34:58 -0700nmm1@cus.cam.ac.uk (Nick Maclaren) writes:
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: [Lit.] Buffer overruns Newsgroups: sci.crypt,alt.folklore.computers Date: Fri, 11 Feb 2005 12:44:24 -0700pornin@nerim.net (Thomas Pornin) writes:
The other problem that was epidemic at that time was dangling finwait chains caused by http protocol. tcp connections had never before been invisioned to have huge numbers of short-lived connections, each one generating a dangling finwait. there was a period when some large (web/http) servers were loosing 95 percent of their cpu to processing the dangling finwait chain. sequent had rewritten their dangling finwait processing before because of 20,000 relatively long lived connections would produce a fair sized dangling finwait list ... and so was also applicable to handling huge numbers of short-lived connections.
trivia question ... when it came time to change the name from mosaic to netscape ... from who did they get the name "netscape"?
a couple past postings mentioning mosaic, netscape, payments,
ssl, and electronic commerce:
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3
some past postings mentioning finwait
https://www.garlic.com/~lynn/99.html#1 Early tcp development?
https://www.garlic.com/~lynn/99.html#164 Uptime (was Re: Q: S/390 on PowerPC?)
https://www.garlic.com/~lynn/2000c.html#52 Does the word "mainframe" still have a meaning?
https://www.garlic.com/~lynn/2002.html#3 The demise of compaq
https://www.garlic.com/~lynn/2002.html#14 index searching
https://www.garlic.com/~lynn/2002i.html#39 CDC6600 - just how powerful a machine was it?
https://www.garlic.com/~lynn/2002j.html#45 M$ SMP and old time IBM's LCMP
https://www.garlic.com/~lynn/2002q.html#12 Possible to have 5,000 sockets open concurrently?
https://www.garlic.com/~lynn/2003e.html#33 A Speculative question
https://www.garlic.com/~lynn/2003h.html#50 Question about Unix "heritage"
https://www.garlic.com/~lynn/2004m.html#46 Shipwrecks
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/