List of Archived Posts

2005 Newsgroup Postings (01/31 - 02/12)

[Lit.] Buffer overruns
4shift schedule
[Lit.] Buffer overruns
The mid-seventies SHARE survey
Anyone know what the 'clipper' chip looks like ?
[Lit.] Buffer overruns
[Lit.] Buffer overruns
[Lit.] Buffer overruns
The mid-seventies SHARE survey
The mid-seventies SHARE survey
[Lit.] Buffer overruns
The mid-seventies SHARE survey
The mid-seventies SHARE survey
[Lit.] Buffer overruns
[Lit.] Buffer overruns
[Lit.] Buffer overruns
[Lit.] Buffer overruns
[Lit.] Buffer overruns
[Lit.] Buffer overruns
[Lit.] Buffer overruns
[Lit.] Buffer overruns
[Lit.] Buffer overruns
[Lit.] Buffer overruns
Volume Largest Free Space Problem... ???
[Lit.] Buffer overruns
[Lit.] Buffer overruns
[Lit.] Buffer overruns
[Lit.] Buffer overruns
[Lit.] Buffer overruns
[Lit.] Buffer overruns
[Lit.] Buffer overruns
XML Encryption
[Lit.] Buffer overruns
[Lit.] Buffer overruns
[Lit.] Buffer overruns
[Lit.] Buffer overruns
The mid-seventies SHARE survey
[Lit.] Buffer overruns
[Lit.] Buffer overruns
[Lit.] Buffer overruns
[Lit.] Buffer overruns
Oldest active information system
[Lit.] Buffer overruns
History of performance counters
[Lit.] Buffer overruns
History of performance counters
History of performance counters
[Lit.] Buffer overruns
[Lit.] Buffer overruns
[Lit.] Buffer overruns
[Lit.] Buffer overruns
[Lit.] Buffer overruns
[Lit.] Buffer overruns
[Lit.] Buffer overruns
12-2-9 REP & 47F0
[Lit.] Buffer overruns
intel's Vanderpool and virtualization in general
Thou shalt have no other gods before the ANSI C standard
Thou shalt have no other gods before the ANSI C standard
intel's Vanderpool and virtualization in general
intel's Vanderpool and virtualization in general
comp.arch thread "intel's vanderpool and virtualization in general" ,,, fyi
Thou shalt have no other gods before the ANSI C standard
intel's Vanderpool and virtualization in general
Is the solution FBA was Re: FW: Looking for Disk Calc
Thou shalt have no other gods before the ANSI C standard
looking to buy a working DX box
intel's Vanderpool and virtualization in general
Thou shalt have no other gods before the ANSI C standard
intel's Vanderpool and virtualization in general
[Lit.] Buffer overruns

[Lit.] Buffer overruns

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 -0700
Anne & Lynn Wheeler writes:
the result was actually less code, ran much faster and had more function ... besides not having lots of failure modes. part of the problem was that the code i had modified had somewhat evolved over nearly ten year period with new feature/function periodically being grafted on. I rewrote nearly the whole operating system I/O subsystem from scratch which had a side effect of resulting in significantly less code, faster code, no failures, and more function.

long ago and far away in another lifetime, it periodically crossed my mind that everything would be much simpler and better if they stopped letting other people ship code ... in part there would be a lot less for me to fix afterwards. i eventually outgrew it.

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

4shift schedule

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 4shift schedule
Newsgroups: alt.folklore.computers
Date: Mon, 31 Jan 2005 11:39:39 -0700
there 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/

[Lit.] Buffer overruns

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:
I suspect she was referring to the cpu, of which of course there could multiple in a given computer. Even the CDC6400 (40 years ago) could simultaneoussly execute two instructions simultaneously in certain streams.

the 195 genre ('71) had 64 instruction pipeline, register coloring, etc ... It had a problem that a branch instruction (modulo loop sequence within the pipeline) resulted in draining the pipeline (no speculative execution, etc).

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/

The mid-seventies SHARE survey

Refed: **, - **, - **, - **, - **, - **
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 -0700
glen herrmannsfeldt writes:
The ITEL 7330 was a 3330 clone that would run on S/360, at least it would on the 360/91. I am not sure about the channel question as far as the 91 goes.

and might run on the 85, 75, some possibility in 65 (i.e. the 65 tended to have one or two channels that you could attach 2301 drum ... which read/wrote 4heads in parallel and transfer rate about 1.5mbytes/sec). it wouldn't support 3330 block multplexor operation with set sector commands on machines that didn't have block multiplexor channels (i have some vague recollection there is some possibility that 85 was late enuf in the engineering cycle that it might have gotten block multiplexor channel).

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/

Anyone know what the 'clipper' chip looks like ?

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:
Yes, thanks guys, though it seems I made a mistake, I was mixing clipper up with skipjack. The device is some sort of fortezza thing from 'kasten chase applied research'. This doesn't have the same noteriety, so I probably won't keep any chips from it ;o) In any case I can only find chips from the normal manufacturers.

clipper was chip with that thing called LEAF
http://www2.gsu.edu/~lawppw/lawand.papers/dwilson.html
http://encryption_policies.tripod.com/us/denning_0795_clipper.htm

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/

[Lit.] Buffer overruns

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 -0700
Paul Rubin <http://phr.cx@NOSPAM.invalid> writes:
You mean databases? Maybe true. Now look at the extreme measures that app developers take to keep the databases away from the internet. E.g. a typical public-facing banking system these days has an application written in Java (with, natch, GC) followed by a hardware firewall followed by the database, even though both the app and db layers are inside a security boundary. And they still live in dread of some SQL injection attack taking over the database. I haven't figured out the precise reason for the firewall (maybe just superstition), but it's a typical practice anyway.

the more complex and greater magnitude the manual operations ... the higher probability of mistake that might be exploited.

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/

[Lit.] Buffer overruns

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
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 -0700
Paul Rubin <http://phr.cx@NOSPAM.invalid> writes:
I ship when I believe there are no bugs. I leave the safety checks enabled in case my belief turns out to be wrong. If you're a stunt pilot and you wear a parachute, does that mean you're assuming you're going to crash the plane?

when i shiped the resource manager ... i ran 2000 benchmarks that took 3 months elapsed time. the problem with the resource manager was that issues with bugs included any problems with the performance of the system (i.e. say might have 300 active users all with default fairshare scheduling policy, you then give one user allocation of twice fairshare and then have to verify that it operates as designed across a large array of different workloads and configurations).

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/

[Lit.] Buffer overruns

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
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 -0700
Anne & Lynn Wheeler writes:
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


when you start talking about five and six nines availability ... you pretty much move out of the relm of "perfect code" and "no failures" and are well into techniques for failure isolation or failure fencing and failure recovery ... because you quickly realize that you aren't going to have perfection.

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/

The mid-seventies SHARE survey

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 -0700
sidd@situ.com () writes:
how did you fix it ?

split the application library file into set of much smaller files that were each much faster to search ... and then replicated them.

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/

The mid-seventies SHARE survey

Refed: **, - **, - **
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 -0700
one 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/

[Lit.] Buffer overruns

Refed: **, - **, - **
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 -0700
Brian Inglis writes:
Was that used for 801 microcode in channel controllers and 9370 processors?

pl.8 is billed as a pli subset ... the original cp.r operating system for 801 was written in pl.8 as was just about every other based 801 programming (other than unix stuff). cp.r on ROMP was going to be a displaywriter replacement ... when that project got canceled they decided to retarget ROMP to the unix workstation market. They hired the same company that had done AT&T unix port to the PC for PC/IX ... to do somewhat similar port to ROMP. However, instead of porting to the bare metal ... they defined an abstract machine interface and wrote a micro-kernel called VRM (virtual resource manager) in PL.8 was the layer provided the abstract machine interface and the bare metal.

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/

The mid-seventies SHARE survey

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 -0700
Mike Kingston writes:
In 1966, 360/75 at Rutherford High Energy Laboratory had 512K in a cabinet similar to that shown in pic above - don't recollect having seen it. They also had 1 megabyte Large Core Storage with a cycle double that of the main core storage, in a stand-alone cabinet about 6 feet tall and base 2ft 6in or 3ft square, glazed cabinet sides.

One day it suffered what I guess was a dry joint. Not sure how manufacturing made these wire attachments, but IBM officially said "no way to repair that". Brave and skilled IBM account CEs located and soldered the dry joint.

On another topic in neighbouring Harwell account, customer ordered 360/67 with red cabinets, to the horror of account SE at the thought of living with that colour. He said in jest - no software support for red machines, and what happened?..........


the story i was told was that the original 360/60 and 360/70 announcements were for similar 1microsecond memory (i.e. numbers went 30, 40, 50, 60, 70 ... & 62 for the virtual memory version of the 60). before ship, there was better technology with 750ns memory and the model numbers were changed to 360/65, 360/67, and 360/75).

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/

The mid-seventies SHARE survey

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 -0700
Peter Flass writes:
I'm astonished that it would work like that. Obviously the timing wasn't too critical anywhere between the device and the CPU!

os/360 had another kind of failure mode .. the 1052-7 used as operator consoles on most 360 machines ... and if the 1052-7 ran out of paper, an intervention required would be presented to the system. os/360 when it got an intervention required would ring the system bell (load) and stop (the system bell could also be rung for various other reasons ... so it wasn't absolutely determinable what the problem was).

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/

[Lit.] Buffer overruns

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 -0700
daw@taverner.cs.berkeley.edu (David Wagner) writes:
I think you may be coming to the wrong conclusion. The thread started with several people (myself included) arguing in favor of the benefits of type- or memory-safe languages, or if you must use C, C with ABC. One or two people objected that ABC is pointless and unnecessary and that C without ABC is fine if you use professional software engineering practices of sufficient rigor, and that everyone ought to be using those practices in any event. If I appear focused on C, it is because I am responding to this claim about C without ABC vs C with ABC.

I agree with your more general point, which is that the choice of languages, libraries, and programming environment can have an impact on security.


if the target storage area has a length/size that is not determinable by the infrastructure (say no pointer+length paradigm found in some infrastructures ... even in infrastructures using assembler language programming) ... which then requires the programmer to specify the size of the target storage area ... and there are some number of buffer overflow failures because the programming has incorrectly specified the size ... then it is also possible that the programmer would incorrectly specify the target storage location size to any ABC.

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/

[Lit.] Buffer overruns

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 -0700
slight 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/

[Lit.] Buffer overruns

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 -0700
Phil Carmody writes:
I just tried it out, and it seems that /dev/zero is quite happy being opened for write, and that copy-on-write seems to be taking place, and that it's of course zero-initialised to start with. I hit swap too, with larger parameters, and it still behaved as expected (by me, but not by you it seems).

one of the (early) optimizations i did to cp67 when an undergraduate was change zero-filled pages. the original cp67 had a special zero-filled page formated on the boot volume disk ... newly created address spaces were all initialized to having their backing store page pointing to the record (and the RECOMP flag set ... that if the page was ever changed and selected for replacement ... it required recomputing a new backing store location for the page out).

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/

[Lit.] Buffer overruns

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:
Was it possible with apprpriate permission to modify that page?

you could modify any storage resident page that had been fetched from that zeros disk page. however, the page replacement algorithm ... when it decided it had to be moved back to disk ... would honor the RECOMP-flag and recompute a new disk backing store location (and reset the RECOMP flag). Accessing the disk location containing the (system) zeros page took special access privileges (basically write access to the "raw" disk, something that somebody building a new replacement kernel might have ... basically modify the disk location was on par with building a new production kernel).

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

[Lit.] Buffer overruns

Refed: **, - **, - **, - **, - **, - **
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:
The only major gap I detect in the above is that a domain expert is often quite valuable in that the software experts may share a misinterpretation of the requirements and specs that becomes illuminated during the review. If security is a serious issue then a security expert becomes mandatory because the engineering staff are intent upon what the code _should_ do while the security expert will be intent upon what the code _should_not_ do.

in review of one of the FAA ATC modernization projects ... that issue was raised ... but possibly not the way you think. a design and implementation had been done predicated that hardware and operating system software could mask all failures from the actual application. however, as you walked thru the ATC process ... it turns out that there were some number of possible failures/errors at the domain processing level (unrelated to hardware and/or software bugs/errors).

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

[Lit.] Buffer overruns

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
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:
Was it possible with apprpriate permission to modify that page?

or are you talking about the page(s) in memory instead?

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):
http://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/

[Lit.] Buffer overruns

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 -0700
Brian Inglis writes:
Totally untrue. Often systems are built of disparate components by different people over a (short) period of time. You have to unit, regression, and system test each piece from the backend out to the frontend, assuming no tight dependencies which require all pieces be updated together, before you can be sure you've got a new stable release.

and if you have a rock solid interface specification like the 360 prinicple of operations ... that each side validated against ... then you could have some level of development independence. of course that started to get more complicated as creative uses of the DIAGNOSE instruction became common.

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

[Lit.] Buffer overruns

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
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
https://www.garlic.com/~lynn/2004p.html#9 vm/370 smp support and shared segment protection hack
https://www.garlic.com/~lynn/2004p.html#10 vm/370 smp support and shared segment protection hack

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/

[Lit.] Buffer overruns

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 -0700
Paul Rubin <http://phr.cx@NOSPAM.invalid> writes:
The IETF requires not one but two separate, independently written, interoperating implementations of any spec to exist before they'll approve the spec as a draft standard. I think they understand the difficulty.

which is one of my favorite things about ISO standards ... an example was their insistence that all networking standards had to conform to the OSI model. ISO standards don't require any demonstration of useability or feasability.

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

  1. bypassing OSI model transport/network interface

  2. supporting internetworking protocol ... which violates OSI model

  3. supporting MAC/LAN inferface, MAC/LAN interface sits somewhere in the middle of networking layer ... which violates the OSI model ... so anything that interfaces/supports MAC/LAN interface also violates OSI model.

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

[Lit.] Buffer overruns

Refed: **, - **, - **, - **
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 -0700
Paul Rubin <http://phr.cx@NOSPAM.invalid> writes:
"Writing is the easy part. Deciding what to write is the hard part".

even harder is deciding what not to write (and KISS).

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/

Volume Largest Free Space Problem... ???

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 -0700
shmuel+ibm-main@ibm-main.lst (Shmuel Metz , Seymour J.) writes:
The 2321 was not[1] a disk drive. BB had to be zero for every disk drive, every drum and even the virtual disk drive (3330V) to the 3850 MSS. The 2321 was the only DASD that used nonzero BB. I believe that you are correct as to which CCW data areas included a BB field, with the possible exception of a maintenance CCW or two.

[1] What it was cannot be said in polite society.


drums and data-cells are part of the reason that it is called DASD ... *direct access storage device* ... as opposed to just disks, i.e. there was stuff that while while it may have been brown were flat round platters.

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/

[Lit.] Buffer overruns

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:
No I was specifically wondering about the zero-page, since it could have been a trojan host.

as mentioned
https://www.garlic.com/~lynn/2005c.html#16 [Lit.] Buffer overruns

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/

[Lit.] Buffer overruns

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: [Lit.] Buffer overruns
Newsgroups: alt.folklore.computers
Date: Thu, 03 Feb 2005 08:31:37 -0700
Anne & Lynn Wheeler writes:
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):
http://www.multicians.org/site-dockmaster.html


a random dockmaster sighting from google groups:
http://groups-beta.google.com/group/comp.risks/msg/642ef01efd359b0a?dmode=source

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

[Lit.] Buffer overruns

Refed: **, - **, - **, - **
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:
I wouldn't necessarily count crackers as incompetent. Indeed, some are quite competent at what they do; these are the ones you hear about being hired as security consultants.

In their place, though, I'd add those management types who have a vested interest in the failure of a project.


a few years ago, we had a mini security conference at our house and one of the refains by university security graduate program was motivating the students to work on creating secure infrastructures rather than working on garnering bragging rights by finding the next exploit.

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

[Lit.] Buffer overruns

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
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 -0700
cmadams@hiwaay.net (Chris Adams) writes:
OSF/1^UDEC^WDigital Unix^WCompaq^WHP Tru64 Unix has overcommit in the form of "lazy" swap allocation. The kernel only allocates swap when it is needed, and if it can't, it starts killing processes (including kernel processes).

part of the issue with page backing store allocation policy is whether or not you have dups or not ... especially with large real memories. I had done dynamic adaptive dup/no-dup allocation algorithms in the late '70s. with a dup algorithm, once a disk location is allocated on initial page out ... then it remains allocated even on subsequent page in operations (i.e. there are two copies, one in memory and one on disk). if the page then is selected for replacement ... and it hasn't been modified during the most recently stay in storage ... then the copy on disk could be considered still valid ... and you avoid the page-out operation. in the no-dup scenario ... the backing storage location is released as soon as a page is read into memory.

"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/

[Lit.] Buffer overruns

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
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 -0700
daw@taverner.cs.berkeley.edu (David Wagner) writes:
I don't have the numbers. The distribution of bugs falls off very quickly after that, making it hard to identify a single bug that is anywhere near as prevalent as buffer overruns.

near the start of the thread i made some references to stats that i've pulled from cve database and exploit descriptions.
https://www.garlic.com/~lynn/2004q.html#74 [Lit.] Buffer overruns

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/

[Lit.] Buffer overruns

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 -0700
Randy Howard writes:
There are a lot of different ways to exploit security problems, and buffer overruns certainly get the press, but there are a lot more methods, and I'm not sure that buffer overruns aren't dropping as we speak versus other approaches. Admittedly they are very common, but more and people know about them and how to avoid them.

An interesting article related to all of this is here:
http://research.microsoft.com/users/jpincus/beyond-stack-smashing.pdf


note that exploits of buffer overflow problems in c language environment have been known for 15-20 years ... not only do they get the press ... but more recently they are even getting their very own hardware and operating system countermeasure.

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/

[Lit.] Buffer overruns

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 -0700
Randy Howard writes:
Yes. In fact, the authors of "The Shellcoder's Handbook" point out that this very thing has been done over the last few years with the bulk of the open source community software, resulting in very few buffer overrun problems. 10,000 reviewers looking for such things makes for a powerful cleanup party. The claim is that they are very rare today in open source software. Judging by the number of buffer overruns in commercial software versus open source, I think they're probably correct.

the issue that the quoted data is from ... is not from buffer overflow problems ... it is from exploits of buffer overflow problems. The analysis didn't examine the number of buffer overflow software bugs as percentage of all software bugs ... they examined the causes of exploits and compromises and found that buffer overflow problems account for 20% of the cause of all exploits and compromises. this has been going on for possibly 20 years or more. the Linux magazine feb. 2005 article (pg. 38) mentioned that buffer overflow exploit gained widespread notoriety in 1988 with the Morris worm.

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/

XML Encryption

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: XML Encryption
Newsgroups: sci.crypt
Date: Fri, 04 Feb 2005 08:29:58 -0700
alastairgarrow@aol.com (Alastair Garrow) writes:
Thanks for reply. I do understand the difference but perhaps I never explained it well. My understanding of encryption is that original data, once encrypted, will be increased in size by the addition of the key. Compression follows that. My understanding of XML encryption is that encryption can be selective e.g. I could have encrypted every third word of this message and left the rest in full view. This being the case, I assume the main benefit of selective encryption is to avoid some of the processing and transmission difficulties with compressed and encrypted data. An example might help - If I encrypted 100kb of data with a key that adds a 10% overhead, that would be 110kb before compression. If I only had to encrypted 10kb of that 100kb then I would have 90kb + 11kb (10kb with the 10% overhead) = 101kb before encryption.

there are certain public key related paradigms that allow for the attachment of a digital certificate as part of verifying a digital signature. The digital signature isn't actually an encryption of the data but an encryption of the hash of the data ... it is used by the recipient for determining the integrity and origin of the transmitted data.

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/

[Lit.] Buffer overruns

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
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 -0700
Randy Howard writes:
Yes. In fact, the authors of "The Shellcoder's Handbook" point out that this very thing has been done over the last few years with the bulk of the open source community software, resulting in very few buffer overrun problems. 10,000 reviewers looking for such things makes for a powerful cleanup party. The claim is that they are very rare today in open source software. Judging by the number of buffer overruns in commercial software versus open source, I think they're probably correct.

attached is partial repeat of a post from last summer
https://www.garlic.com/~lynn/2004j.html#58 Vintage computers are better than modern crap!

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

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

[Lit.] Buffer overruns

Refed: **, - **, - **, - **, - **
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 -0700
jmfbahciv writes:
Ah. [emoticon get a glimmer] BLT (BLock Transfer) A PDP-10 instruction that would transfer contents from addr1 to addr2 and could be interrupted.

It would have been simpler and taken less time if you had simiply put a ? after the word.


360 had MVC instruction with a single length field (but only 256 bytes, aka it applied to both the origin and target). MVC was an interesting case for 360/67 virtual memory support since worst case could involve eight page address .... (1&2) execute instruction possibly crossing a page boundy ... (3&4) executing a MVC instruction crossing a page boundary ... (5&6) source crossing a page boundary and (7&8) target crossing a page boundary.

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/

[Lit.] Buffer overruns

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 -0700
this may or may not be considered a reflection on views about the quality of c & c++ programming languages
http://www.zdnet.com.au/news/security/0,2000061744,39179932,00.htm

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/

[Lit.] Buffer overruns

Refed: **, - **, - **, - **, - **, - **, - **, - **
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 -0700
Paul Rubin <http://phr.cx@NOSPAM.invalid> writes:
Some of the old CISC architectures let you do an array lookup with ABC in one instruction. I don't see why that can't be brought back. It used to be done with microcode but these days the ABC can use parallel hardware and stop or back out the instruction in the case of an ABC fault. There would still be some cost in gates and cache load, but the scheme should still decrease ABC's performance impact considerably.

the SLT (search list) RPQ instruction for the 360/67 could run on forever (i believe it was originated by lincoln lab).

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/

The mid-seventies SHARE survey

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 -0700
blackhole_for_spam@the_skip.invalid writes:
Right at the top of this posting the discussion was about a belt falling of a 7330 disk drive unit. This is a IBM330 compatible drive unit. You say above that you cannot speak for the IBM units, and go on to comment about technology being the same as disks used to discuss disks used on IBM XT and AT.

I think the only similarity between those disks and the 3330 disks is that they use magnetic surface, R/W heads and the disks rotate.

On 3330 seeks are controlled by counting the number of servo tracks passed over and reading / writing is clocked from pulses on the servo track, i.e the data is not self clocked aka IBM23xx disk drives.


remember that real 3330s had 20 surfaces and 20 heads ... but only 19 were used (and addressable) for data. they could also use the 20th head/surface for rotational position ... if the rotational position of records were determinable by the programmer then they could do set-sector channel programs where the channel, controller and string switch could be freed until the disk had rotated into position.

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/

[Lit.] Buffer overruns

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 -0700
Mack <macckone@a_nospamjunk123_ol.com> writes:
After looking back through a 1000 posts or so I found the reference to the code in question. After looking at the difference between how it would be handled in x86 assembly (which generally won't allow two memory accesses in the same instruction) and ADA, the problem is obvious. In the code in question a check if j==i is needed. Sometimes lower level languages ARE better.

note in the 360 & 370 machine instruction paradigm previously mentioned ... the move instructions required the length of the storage areas before beginning the operation (establishing bounds with explicit length values) ... as contrasted to the typical C language string convention which starts the operation and only discovers the bound of an area by running into a specific data pattern in storage (as opposed to actually having the length before the operation begins)

... 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/

[Lit.] Buffer overruns

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
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 -0700
Anne & Lynn Wheeler writes:
one of the other most convoluted was luther woodrum's tree stuff that was adapted for stuff like sorting.

slightly dift from luther's partition tree stuff (that he spent something like ten years getting into the hardware) ... we did radix partition search for the online phonebooks.

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/

[Lit.] Buffer overruns

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 -0700
Mack <macckone@a_nospamjunk123_ol.com> writes:
I generally use the bounded version of the string copy operation (strncpy). But I am not sure that is really relevant to the XOR swap debate.

it wasn't in response to the XOR part ... it was in response to the comment related to sometimes assembler/machine language paradigm can be more applicable than higher level language.

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

[Lit.] Buffer overruns

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 -0700
Randy Howard writes:
Yes. In fact, the authors of "The Shellcoder's Handbook" point out that this very thing has been done over the last few years with the bulk of the open source community software, resulting in very few buffer overrun problems. 10,000 reviewers looking for such things makes for a powerful cleanup party. The claim is that they are very rare today in open source software. Judging by the number of buffer overruns in commercial software versus open source, I think they're probably correct.

i thumbed thru a copy just now in the book store and checked the index .. the references to buffer overflows is almost non-existent.

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/

Oldest active information system

Refed: **, - **, - **, - **
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 -0700
Shelley.Giles@ibm-main.lst (Giles, Shelley) writes:
My employer has some programs which were written around 1972 and are still running production jobs. There may have been some minor changes over the years for new versions of OS/MVT and for year 2000.

the claim has been that the NIH's NLM library system was written in the late 60s using bdam ... when i looked at it a few years ago ... it was still bdam.

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

[Lit.] Buffer overruns

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
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 -0700
Mack <macckone@a_nospamjunk123_ol.com> writes:
I have used that trick before also. It doesn't work too well for the swap scenario because the operation isn't atomic. With XCHG the operation becomes atomic. Having said that a RMW cycle is useful for modifying memory locations with outside interference. On 32 bit x86 systems the XCHG instruction is automatically assumed to have a LOCK prefix. The XOR must have it added. This is a feature of the x86 and doesn't necessarily apply to other processors. I always thought that allowing a RMW cycle to be interleaved was a bit brain damaged but that is the way the processor specs say it works. I don't think it would happen in reality because the memory controller wouldn't allow it, but the specs say it can happen so you have to program for it.

charlie invented compare&swap at the science center
https://www.garlic.com/~lynn/subtopic.html#545tech

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/

History of performance counters

Refed: **, - **, - **, - **, - **, - **
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:
I think in Poughkeepsie the location of the rest rooms was IBM Confidential. :-)

In Rochester, the idea that the CE would use a scope was totally foreign. We were lucky if we could get them to use a voltmeter. There was a "logic probe" switchable for MST or SLT that would light a light to show 1 or 0 on a pin.


the following is a tale of online telephone book application
https://www.garlic.com/~lynn/2005c.html#38 [Lit.] Buffer overruns

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/

[Lit.] Buffer overruns

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
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 -0700
Brian Inglis writes:
Good marketing for AMD vs Intel; necessity for MS when the number of buffer overflows and security bugs seems to be climbing, not dropping. It may not be too hard for Apple to port MacOS X ("No viruses!") to the next PC platform.

remember current mac/os (and NeXT) is a derivative of mach from cmu ... a unix microkernel implementation.

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/

History of performance counters

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
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 -0700
Lee Witten writes:
When I worked there, every terminal and computer had a sticker that said "This equipment can be used for IBM Mangement Approved Purposes only", or some such statement. And I got a huge laugh when someone put one of those stickers on all the urinals in the IBM Mens Room! Such naughtyness was rare at IBM!

part of that was from an early incident involving corporate people coming into doing a site security audit in san jose. we eventually escalated with a challenge to the security people that people's personal computing facilities should be treated similarly to their physical office, desk, phone, etc .... and we provided a draft update to some of the wording for corporate management manuals to reflect the situation.

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/

History of performance counters

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 -0700
note, 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/

[Lit.] Buffer overruns

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:
There shouldn't be. The primary purpose of assembly language is for the programmer to specify *exactly* what machine instructions (at the ISA level) are used and in what way. Very few ISAs even have the concept of a bounded array (apart possibly from a memory segment, which generally isn't suitable for that purpose).

although there are machine instructions that require explicit length bounds before the instruction starts ... so there are some instruction semantics that require that both origin and destination lengths are explicitly known as part of invoking the instruction (as part of the instruction semantics). this tends to promote infrastructures with determinable storage area lengths as part of invoking the instruction ... as compared to infrastructures where lengths are actually explicit ... like strings where the boundaries are actual length paradigms but implicit in data structures embedded in the storage areas.

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/

[Lit.] Buffer overruns

Refed: **, - **, - **, - **, - **, - **
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 -0700
Friday, 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
https://www.garlic.com/~lynn/index.html#glosnote

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/

[Lit.] Buffer overruns

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 -0700
infobahn writes:
Sense 8, I presume.

yeh, it is sort of like buffer overflows ... no matter what the theory is ... once a large number of people start doing it ... it is almost impossible to stamp out (w/o totally changing the paradigm). there was that unfortunate incident with cbs 60 minutes in the 80s that they had to promise to not use that form if they were allowed to come and film ... and that night on the show, they did it anyway (that and the bit about clandestine meetings in the santa cruz mountains).

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

[Lit.] Buffer overruns

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
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 -0700
infobahn writes:
Sense 8, I presume.

i've got an original, mint condition, v2.7.1 dated mar91 softcopy ... i think that I contributed to some website trying to collect complete history (as well as an autographed hard copy, also 1991).

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/

[Lit.] Buffer overruns

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
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 -0700
Mack <macckone@a_nospamjunk123_ol.com> writes:
In that case you should probably move the crackers to the can-do list. They can and do help make things work by finding problems and demonstrating them. I won't get into the whole black-hat/white-hat debate. We should all know there are good guys and bad guys out there looking for security holes. Certain programming shops (really big ones), don't fix problems until there is an active attack against that problem.

so june 17th of some year ... the largest online service provider started having one of its internet connected service crash. for the next two months they had everybody they could think of come in to look at it ... but it continued to crash. so aug. 17, somebody came out and bought me a hamburger after work and while i ate it ... explained the symptoms. i then gave him a q&d work around patch that was applied later that night.

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/

[Lit.] Buffer overruns

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:
But if the programmer specifies the wrong length the computer will merrily proceed to process it; that's not ABC.

but the earlier discussion we had was that dynamic buffers (in c) required programmers to specify the length value in subsequent operations ... and that any competent programmer would always specify the correct length ... and that an incorrect length would never be specified.

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/

[Lit.] Buffer overruns

Refed: **, - **, - **
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 -0700
jmfbahciv writes:
Wasn't it put under a feature test switch?

cp67/cms to vm370/cms transition involved significant rewrites of most of the cp67 kernel (to "clean up the code") ... while CMS transition was primarily changing from the cambridge monitor system to the conversational monitor system (and moving around some cms code to align it on 370 64k segment boundary).

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/

12-2-9 REP & 47F0

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
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 -0700
paul c writes:
the comments in the buffer overrun thread about patches take me back in time. around 1970, the programmers where i worked got Sunday evening hands-on time (during the week, testing was 'remote' - we packaged up our card decks on the dumb-waiter for our two test shots per day plus one overnight. even though we usually had 2 or 3 programs on the go, this still left lots of time to work on cryptic crosswords).

i felt kind of silly when i finally discovered 12-2-9 REP cards ... which you could keyboard plain character ... rather than having to multiple punch hex.

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/

[Lit.] Buffer overruns

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: [Lit.] Buffer overruns
Newsgroups: alt.folklore.computers
Date: Tue, 08 Feb 2005 00:07:20 -0700
how 'bout a similar thread from 2002 x-posted to sci.crypt and a.f.c?
https://www.garlic.com/~lynn/2002.html#24 Buffer overflow

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/

intel's Vanderpool and virtualization in general

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
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 virtualization products exist because people are willing to pay money for them. Apparently some customers feel there are OS failings that are addressed by these products or they wouldn't be buying this stuff. Whether that perception is true or not is debatable given the 'improvements' that Intel is claiming for this technology: dedicating resources in multiple user environments and improved defenses against viruses or spy ware.

so if you want something of the historical evoluation ... cp/40 was done for a 360/40 with custom modified virtual memory hardware. when the standard virtual memory processor came out, the 360/67 ... cp/40 was retargeted to 360/67 (even tho the virtual memory architecture was somewhat different). bunch of science center stuff
https://www.garlic.com/~lynn/subtopic.html#545tech

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/

Thou shalt have no other gods before the ANSI C standard

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 -0700
paul c writes:
i'm pretty sure they weren't 2741's which i seem to remember had a little tiny screen which these didn't, just a typewriter, keyboard and a box of paper. not sure if 2741's came out with 360 but these terminals pre-dated S/360. it's so long ago that i could be wrong, well even if they were recent, i could still be wrong. i seem to remember that the model number was 3 digits. that would be in keeping with the smaller number of bits in the code! can't even remember if they had the golfball-platen thing.

2741 was beefed up selectronic typewriter (golf-ball) ... it was in self-contained desk high package .... basically something like a computer table ... with the typewriter embedded in the table. it was 134.5 ... slightly faster than 110 to be incompatable line-speed.

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/

Thou shalt have no other gods before the ANSI C standard

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 -0700
and 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
http://www.multicians.org/thvv/360-67.html

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

intel's Vanderpool and virtualization in general

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
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 -0700
nmm1@cus.cam.ac.uk (Nick Maclaren) writes:
C) Related to the first point, a good VM system will reduce the number of times that you have to physically go to the machine to reset it or, worse, reinstall firmware or, even worse, replace irredeemably broken hardware. Yes, a student CAN corrupt firmware so badly that the only solution is to replace the device.

All of these advantages were known before 1970, though the last was regarded as a misdesign in the system. It isn't now :-(


almost. the 370 virtual memory architecture came out long before there was actually hardware built for it ... and it had numerous differences (table formats, instruction op code, etc) from the implementation in the 370/67. so a joint project was started between endicott (building 370/145) and science center (originated cp67) to create a special kind of virtual machine under cp67 that simulated 370 virtual memory virtual machines (as opposed to simulated 360 virtual machines).

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/

intel's Vanderpool and virtualization in general

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 -0700
Andrew Reilly <andrew-newspost@areilly.bpc-users.org> writes:
This assumes that the operating system is so weak that it can only support one application, and so you need to keep the operating-system-instance/application-instance pairing that you were forced into when you went to the one-application-per-box model. Not all operating systems are so weak, and system administrators shouldn't be so eager to treat them as just the library needed to provide the api to run the application, exo-kernel style.

Oh, your applications use different OSes? Which ones? In the Windows/Business universe, all applications are Windows applications. Sure, in the Linux universe you might also want to run some Windows applications, but does Intel really care enough about that niche to add virtualization facilities to their processors?

Incidentally, how does virtualization on x86 processors square with the coming DRM-down-to-the-hardware mechanisms? Aren't they inherently incompatible?


from what i've seen it isn't so much an technical operating system issue, it is an infrastructure administrative management issue; the systems have gotten so big providing support for huge numbers of different applications ... that when any administrative activity needs to take place ... it has become impossible to (administratively) coordinate everything. It appears to be much more of a people problem than a technical issue. Being able to partition ... say by business divisions ... means that administrative coordination only has to occur at the business division level instead of across the whole enterprise (say synchronizing tens of thousands of interests rather than large hundreds of thousands of interests).

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

comp.arch thread "intel's vanderpool and virtualization in general" ,,, fyi

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 -0700
some recent posts in comp.arch vanderpool thread
https://www.garlic.com/~lynn/2005c.html#56
https://www.garlic.com/~lynn/2005c.html#59
https://www.garlic.com/~lynn/2005c.html#60

vanderpool webpage
http://www.intel.com/technology/computing/vptech/ press release
http://www.intel.com/pressroom/archive/releases/20050120comp.htm

Thou shalt have no other gods before the ANSI C standard

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 -0700
Andrew Swallow writes:
ASCII was 7 bits. 7 + 1 = 8

Changing the parity bit into 127 other character came later.


but it could be odd or even parity (or the 8th bit was there but no-parity) ... you frequently had one of three options to choose from for the 8th bit.

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

intel's Vanderpool and virtualization in general

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
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:
I agree, and that is about the best justification I have seen for extreme microkernel designs like GNU HURD with almost all OS services in user land. Fewer, better architected interactions between components, easier to debug, restart failed services, etc.

The problem, is that increased context changes reduce performance. This disadvantage may finally be ameliorated with better CPU architectures and many cores on a die.

In future years we may see a merging of VM technology and OS technology into a HURD like design that also provides multiple OS "personalities" and support for multiple OS versions along the lines of the failed IBM Workplace OS and Fort Knox.


there are possibly two separate issues ...

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/

Is the solution FBA was Re: FW: Looking for Disk Calc

Refed: **, - **, - **, - **, - **
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 -0700
cfmtech@ibm-main.lst (Clark F. Morris, Jr.) writes:
I am heartened by the various comments that I have seen on this topic. After reading them, I would like to expand on some of my positions.

I have advocated going to FBA for around 20 years. The reason is simplicity. However, I do not believe that we need to support the non-FBA access methods on FBA devices. I further believe that devices could be more specialized so that some might have VTOCs (hopefully actually something that is better than the current kludge of VTOC, VTOC index and VVDS) while others are organized like disks on Unix. I would not try to expand the 3390 geometry device beyond current limitations because of the number of different places code would have to be changed and the subtlety of the errors that will ensue from making interesting use of existing control blocks.

The advent of z/OS with its subtle and not so subtle impact on control blocks of all kinds is an ideal time to review everything. The size of data items is growing. Already, graphics just don't fit in the 32KB record size limitation. We have been long hobbled by the 8 character restriction on member names, job names and step names. These limitations were necessary when OS could fit in 64K and DOS in 16K for both operating systems and application programs. They somehow are quaint today. Most applications can run as is with a recompile being needed for those files with records larger than 32K. Either z/OS should be functionally terminated with a clear set of migration paths or the current limits removed in a phased manner. I would like to see the latter path.


from long ago and far away, early 80s ... the statement from bldg.90/STL was that even if i gave them fully integrated and tested MVS support for FBA ... it would still cost something like $26m to ship. one issue was ROI ... at the time, they were selling as much disk as they could make ... you had to show that for the $26m that there would be an increase in the business revenue (to offset the $26m expenditure) ... not just replacing one kind of disk drive technology for another kind of disk drive technology.

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/

Thou shalt have no other gods before the ANSI C standard

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:
And there aren't three options, but five: 8 bits, no parity (which can transparently send all 256 values) 7 bits, even parity (perhaps the most common parity setting) 7 bits, odd parity 7 bits, mark parity (parity bit is always set, used in some TTYs) 7 bits, space parity (identical to 8/none for values 0-127)

And every now and then, some brain-damaged piece of hardware manages to switch itself into some totally insane setting like 7 bits, no parity, which makes for truly interesting results that vary depending on what hardware and/or software is listening.


and for total topic drift ... when we were doing the terminal controller clone using interdata/3
https://www.garlic.com/~lynn/submain.html#360pcm

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/

looking to buy a working DX box

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 -0700
mike walter wrote:
Migrating off our ancient Network Systems DX Series "HyperChannel" box keeps getting pushed down lower on our task priority list.

The box we have is older than the last tech who came to repair it. We'd rather not find out that the next time it can't be fixed, and

that there are no available spare parts to order. I'd like to have a spare unit sitting ready here until we get a "round tuit". Ebay, Google, Yahoo. and MSN searches did not turn up anything useful. Does anyone have a working Network Systems DX Series box lying around that they no longer need, and might like to free up the space in their data center? We can negotiate a price for this ancient hardware.


i use to have a 20 or so as part of hsdt
https://www.garlic.com/~lynn/subnetwork.html#hsdt

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

intel's Vanderpool and virtualization in general

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
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 -0700
nmm1@cus.cam.ac.uk (Nick Maclaren) writes:
Er, no, ABSOLUTELY not. Don't even think of it. Study it, yes; take good ideas from it, yes; copy it, no. Remember the quote:

the context change is with respect to permissions, address space, registers, etc. not with respect to execution resource control. this is analogous to some of the GNOSIS stuff ... which turned into keykos. at one point keykos people made some mention that they could do (some kinds of?) transactions more efficiently than TPF (transaction processing facility kernel that is used by airline res and financial transaction systems ... and grew out of the old airline control program).

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/

Thou shalt have no other gods before the ANSI C standard

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:
Please use "in your automobile" or "in your aircraft navigation system" or "in an ATM machine" or "that controls the power grid" or ...

Those are ALL now under attack, and the attacks will probably become more severe and more sophisticated with time.

The good news is that MOST of those attacks have failed, MOST of the time, and FEW people have been killed, so far.


they may have always been under attack ... it just that some of the attacks now involve consumer oriented technology and more likely to make the consumer press.

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

intel's Vanderpool and virtualization in general

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 -0700
nmm1@cus.cam.ac.uk (Nick Maclaren) writes:
What Unix really COULD do with is a lightweight threading mechanism that would enable that for threads within a single process. But it isn't possible to get there starting from POSIX.

darn, you beat me to it ... i wanted to post that ..

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

[Lit.] Buffer overruns

Refed: **, - **, - **, - **, - **, - **, - **, - **
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 -0700
pornin@nerim.net (Thomas Pornin) writes:
At some time a few years ago, ftp.cdrom.com was the biggest FTP site online. It could handle about 700 simultaneously connected users; there was not enough RAM in the machine to get more. By activating overcommit, the number raised to 3000.

This is of course a very specific area, where a random process crash is no big deal: if the memory was too overcommuted, some process gets a segfault and the client is disconnected, but no incorrect data is sent on the wire.

Nevertheless, I find this a good illustration of what overcommit can be good for. Note that overcommit is really useful when you have a big swap area (so that the critical point where one process has to get killed can be reached only after considerable disk thrashing).


some number of years ago, netscape store was the largest ftp site ... they were having to do round-robin dns and router load-balancing across multiple large servers ... and then starting to offer special reserved servers for people who paid more. At some point they replaced them all with a single large sequent server that had been clocked at 20,000 connections (i think it became something like ftp20.netscape.com).

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/

previous, next, index - home