List of Archived Posts

2005 Newsgroup Postings (01/19 - 01/31)

8086 memory space

Foreign key in Oracle Sql

Relocating application architecture and compiler support

[OT?] FBI Virtual Case File is even possible?

Relocating application architecture and compiler support

Relocating application architecture and compiler support

[Lit.] Buffer overruns

[Lit.] Buffer overruns

Relocating application architecture and compiler support

Relocating application architecture and compiler support

Factoring problem, solved

Relocating application architecture and compiler support

[Lit.] Buffer overruns

Relocating application architecture and compiler support

something like a CTC on a PC

something like a CTC on a PC

[Lit.] Buffer overruns

[Lit.] Buffer overruns

CAS and LL/SC

CAS and LL/SC

[Lit.] Buffer overruns

[Lit.] Buffer overruns

The Mac is like a modern day Betamax

360 DIAGNOSE

stranger than fiction

360POO

CAS and LL/SC

Relocating application architecture and compiler support

Relocating application architecture and compiler support

M.I.T. SNA study team

[Lit.] Buffer overruns

[Lit.] Buffer overruns

Noobie SSL certificate problem

[Lit.] Buffer overruns

[Lit.] Buffer overruns

[Lit.] Buffer overruns

Relocating application architecture and compiler support

[Lit.] Buffer overruns

Relocating application architecture and compiler support

[Lit.] Buffer overruns

[Lit.] Buffer overruns

[Lit.] Buffer overruns

[Lit.] Buffer overruns

[Lit.] Buffer overruns

The mid-seventies SHARE survey

[Lit.] Buffer overruns

[Lit.] Buffer overruns

The mid-seventies SHARE survey

[Lit.] Buffer overruns

The mid-seventies SHARE survey

[Lit.] Buffer overruns

History of performance counters

[Lit.] Buffer overruns

The mid-seventies SHARE survey

The mid-seventies SHARE survey

[Lit.] Buffer overruns

[Lit.] Buffer overruns

Keeping score

History of performance counters

The mid-seventies SHARE survey

[Lit.] Buffer overruns

[Lit.] Buffer overruns

The mid-seventies SHARE survey

[Lit.] Buffer overruns

[Lit.] Buffer overruns

[Lit.] Buffer overruns

[Lit.] Buffer overruns

8086 memory space

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 8086 memory space
Newsgroups: alt.folklore.computers
Date: Wed, 19 Jan 2005 18:54:37 -0700

Brian Inglis writes:

That was the automated startup virtual machine that started up the
service machines.
I was trying and failing to remember the VM standard SECUSER machine
that received and responded to or forwarded system or service
machine messages: was it called OPERATOR?

the standard operator login has been operator ... dating back to cp/67
... so that was already in use ... but could use SECUSER to get copies
all the standard system messages normally going to OPERATOR.

a small secuser posting from vmshare archive from 1/12/83:
http://vm.marist.edu/~vmshare/browse?fn=SECUSER&ft=NOTE

misc other secuser postings
http://vm.marist.edu/~vmshare/browse?fn=SEND&ft=NOTE
http://vm.marist.edu/~vmshare/browse?fn=SPY&ft=NOTE
http://vm.marist.edu/~vmshare/browse?fn=TMON&ft=NOTE
http://vm.marist.edu/~vmshare/browse?fn=XASETSEC&ft=NOTE
http://vm.marist.edu/~vmshare/browse?fn=PIPE95&ft=NOTE

PROP (PRogrammable OPerator showed up in the early 80s) misc. PROP
discussion starting in 83
http://vm.marist.edu/~vmshare/browse?fn=PROP&ft=MEMO
http://vm.marist.edu/~vmshare/browse?fn=NO:OPER&ft=MEMO

some discussion from vm/esa mailing list:
http://listserv.uark.edu/scripts/wa.exe?A2=ind9908&L=vmesa-l&F=&S=&P=8551

current programmable operator description from the administrative and
planning guide:
http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/hcsg2a00/5.0?DT=20020402142448

standard/default virtual machine for PROP is the OPERATOR virtual
machine.

and for something (almost) completely different:
http://www-1.ibm.com/servers/eserver/xseries/systems_management/xseries_sm/vmm.html

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

Foreign key in Oracle Sql

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Foreign key in Oracle Sql
Newsgroups: comp.databases.theory,alt.folklore.computers
Date: Wed, 19 Jan 2005 19:50:54 -0700

DA Morgan writes:

I would love to have access to your resources for class preparation
work. And you may well be correct that system/r code is the basic
kernel in DB2 ... but the fact that one came before the other is not
a guarantee that DB2 was built on a system/r foundation or just on
its design. In one sense, given where Larry used to work, one could
say that Oracle too was built on system/r. Would you agree?

i was involved in the tech transfer of system/r to endicott for
sql/ds. i wasn't involved in the transfer of the code back to stl for
db2 (sjr/bldg28 where system/r was done is about 10 miles north of
stl/bldg90 where db2 was done ... both in south silicon valley while
endicott is on the opposite coast). several years ago, the primary
catcher in endicott had his 30th corporate anniversary ... and i
presented him with an email log from the period.

however, in disucssions with one of the people in the following meeting
http://www.garlic.com/~lynn/95.html#13

who had been working at STL at the time, he claims to have almost
single handed managed the transfer of the sql/ds code from endicott
back to stl (for db2).

however, there is lots of work done on that code after it reached stl
... both by people in stl and multiple people at sjr/bldg28 having
worked on system/r (as well as code that was adapted from other
projects).

lots of past system/r references/posts
http://www.garlic.com/~lynn/subtopic.html#systemr

of course there is the sequal reunion web site:
http://www.mcjones.org/System_R/
http://www.mcjones.org/System_R/SQL_Reunion_95/sqlr95.html

a couple specific items about DB2 from the above index:
http://www.mcjones.org/System_R/SQL_Reunion_95/sqlr95-SQL_DS.html#Index287
http://www.mcjones.org/System_R/SQL_Reunion_95/sqlr95-SQL_DS.html#Index290
ttp://www.mcjones.org/System_R/SQL_Reunion_95/sqlr95-DB2.html#Index339
some discussion of other code that went into DB2
http://www.mcjones.org/System_R/SQL_Reunion_95/sqlr95-Spreadin.html#Index271

there were lots of stuff going on in that period, epstein had
graduated from berkeley (out of the ingres project) and was CTO at BLI
... which had a lot of machines in the market. he left BLI to go first
to teradata and then form sybase. when he left bli, there were some
number of BLI people lurking(?) around bldg.28 to backfill epstain's
position. One of the luckers(?) had been a disk engineer at the plant
site in the 60s and had been snarfed up in the Shugart raids ... they
may have even been having meetings at some of the same locations that
Shugart had used (anyway i had some number of after work meetings
about whether to leave or not to leave).

minor epstein reference .... the two BLI name sakes had most recently
come out of memorex:
http://en.wikipedia.org/wiki/Ingres
some discussion from the sql reunion site:
http://www.mcjones.org/System_R/SQL_Reunion_95/sqlr95-Teradata.html
one of my shugart references:
http://www.garlic.com/~lynn/2002.html#17 index searching

there was from scratch open system rdbms done for os2 & aix (i believe
code named shelby, circa 1989, primarily at the time focused on os2)
that was also announced as db2. some of the shelby stuff was also tied
up w/transarc (aka cmu camelot).

now from the dlm work that we had done somewhat implied in this
description
http://www.garlic.com/~lynn/95.html#13

there were a couple people working on (mainframe) db2 that commented
that if we actually did that w/oracle ... it would put things five
years ahead of where they were.

and totally unrelated to most anything
http://www.sleepycat.com/company/management.shtml
and one of the people mentioned in the above reference
also did consulting work on ha/cmp project
http://www.garlic.com/~lynn/subtopic.html#hacmp
and for even stranger reference:
http://dune.mcs.kent.edu/~farrell/sa96/notes/sendmail/usenix.html

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

Relocating application architecture and compiler support

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Relocating application architecture and compiler support
Newsgroups: comp.arch,comp.arch.embedded,alt.folklore.computers
Date: Thu, 20 Jan 2005 09:47:44 -0700

CBFalconer writes:

This technique has been around for a long time, and is the heart of
the old CP/M PRL (page relocatable) format.  I had it highly
automated, as exemplified by the program CCINSTAL and batch job
MAKEDDT.JOB contained in ddtz27.zip.  My CCINSTAL code is dated
1986, and was not new then.  You can examine it all at:

http://cbfalconer.home.att.net/download/cpm/ddtz27.zip

i had done stuff in the early 70s for relocatable shared segments
... i.e. the same code running concurrently in the same shared segment
that resided at different virtual addresses in different virtual
address spaces ... random past posts on the subject
http://www.garlic.com/~lynn/subtopic.html#adcon

i was trying to deal with the problem from a structure that was
basically os/360 conventions with relocatable adcons .... a feature of
executable binaries when stored on disk ... and which would be updated
with fixed addresses when the binaries were brought into memory for
execution. the problem was that the embedded fixed addressess would be
unique to specific location of the executable binary. basically i had
to make addresses relative to value that could be calculated on the
fly.

not quite ten years earlier, tss/360 had dealt with the issue by
separating the code and addresses (as data) ... and that the addresses
could be located in private memory area separate from the instruction.

there were other systems from the 60s that also addressed the same
issue.

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

[OT?] FBI Virtual Case File is even possible?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: [OT?] FBI Virtual Case File is even possible?
Newsgroups: comp.arch
Date: Thu, 20 Jan 2005 12:35:01 -0700

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

CIA Virtual Case File is even possible?
NSA Virtual Case File is even possible?
G[S]IA Virtual Case File is even possible?
NRO Virtual Case File is even possible?

marginally related posting from comp.databases.theory
http://www.garlic.com/~lynn/2005.html#55

with historical reference to one of those agencies ... this has
embedded prior post that also makes obtuse reference to one such
agency.
http://www.garlic.com/~lynn/2005b.html#1

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

Relocating application architecture and compiler support

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Relocating application architecture and compiler support
Newsgroups: comp.arch,comp.arch.embedded,alt.folklore.computers
Date: Thu, 20 Jan 2005 12:50:04 -0700

CBFalconer writes:

I thought the 360 architecture handled relocation very simply from
the beginning, with base registers.

standard instructions used register address plus 12bit
displacement. however os/360 compilers and assemblers generated
intermediate executables that had instructions and data intermixed
... including address constants that conventional programs would load
into registers for use in "relocation".

there was administrative bookkeeping kept at the end of each such file
that listed the location (within the program) of each such address
constant and some (possibly symbolic) information on how to initialize
the address constant when the program was loaded into memory. This
administrative information was commonly referred to as relocatable
adcons (ADdress Constants) .... but they actually became fixed address
constants at the time the program was loaded into memory for actual
execution (aka the executable image out on disk and the executable
image resident in memory tended to defer at least by the swizzling
that went on for such address constants).

so 360 hardware architecture went to all the trouble of making
instruction execution relocatable ... and then, effectively, the
os/360 software guys took some short cuts and established conventions
making the actually executable images in memory bound to fixed address
location.

tss/360 was a parallel operating system effort that was targeted at
time-sharing (aka TSS .. Time Sharing System) designed for 360/67
... which was the only 360 with virtual memory capability. tss/360
operating system conventions went a lot further towards trying to make
sure that the executable image on disk was exactly the same executable
image running in memory ... and preserving the relocatable 360
hardware instruction paradigm.

In os/360 operating system convention the "relocatble address
constants" that were sprinkled thru-out the binary image on disk had
to be swizzled as part of bringing the image into memory for execution
(and at the same time bound the in-memory image to a specific
address).

TSS/360 had a one-level store, page-mapped orientation ... much more
orientated towards what was on disk and what was in memory would be
identical (and address independent).

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

Relocating application architecture and compiler support

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Relocating application architecture and compiler support
Newsgroups: comp.arch,comp.arch.embedded,alt.folklore.computers
Date: Thu, 20 Jan 2005 18:10:23 -0700

glen herrmannsfeldt writes:

To do relocation using base registers would require that the OS
know which registers contained addresses.  There is no hardware
support for that.

however, there was one hardware mechanism of getting a value
of the current instruction into a register for addressability
... w/o there having been loaded from some sort of address
constant ... standard convention of

                BALR  R12,0
                USING *,R12

assembler convention and could also be used by compilers.  Normally,
branch-and-link was used for calls to subroutines with the supplied to
branch address ... and at the same time saving the address of where
the call came from. The above sequence was special case of
branch-and-link, where it didn't actually take any branch but did
establish the current address in a register (w/o requiring any address
constant).

a fairly typical os/360 calling convention is something like:

                L     R15,=A(subroutine)
                BALR  R14,R15

or

                L     R15,=V(subroutine)
                BALR  R14,R15

where =A(subroutine) and =V(subroutine) become address constants that
are internal to the program. In standard os/360, address constants are
embedded inside the program and administrative detail is added at the
end of the program which the program loader uses to swizzle all
address constants to their absolute value when the program is loaded.

While the standard hardware didn't provide relocation of base
registers .... it did provide the BALR convention of establishing an
address on the fly w/o requiring (fixed) address constant and it
didn't preclude software conventions that avoided the use of fixed
address constants embedded in the executable image of the code.

TSS/360 created a different type of convention where on entry to a
program, certain registers had preloaded values ... one of the
registers contains a pointer to block of storage outside the
executable code image ... where various things like address constants
were located. The other convention was something like this

                L    R15,=V(subroutine-executablebase)
                AR   R15,R12
                BALR R14,R15

Where R12 contains "executablebase" for situation invoving
displacements larger than 12bits. In os/360 terms, the value
=A(subroutine-executablebase) is an absolute address constant (not a
relocatible address constant requiring swizzle at program load)
.... amd would be the same/constant value, regardless of the address
that the program image was loaded. I used the above convention a lot
in the early 70s for relocable shared segments.

One argument for =V(subroutine) address constant was that there was
effectively "early binding" of the address (performed at program load
time) ... and saved a register (assigning extra register for the
convention) as well as saving an instruction in each calling sequence.

Now there were 360 machines that did have some additional relocation
provided (not the virtual memory kind found in 360/67). System
engineer on boeing account adapted a version of cp/67 (normally using
paged virtual memory) to run on 360/50(?). My understanding is the
360/50 had something that I think was referred to as a DIL instruction
(not part of standard 360 instruction operation) that was used in
conjunction with some emulation packages (7090?) that allowed
specification of base&bound .... basically a base value that the
hardware added to all address calculations and then checked against
the a bound value. This allowed simple contiguous address relocation
(and required swapping of whole address space ... rather than the more
granular paging available on 360/67.

This would be more akin to the current mainframe implementation of
hardware supported virtual machines called LPARS (logical partitions)
where physical memory can be partitioned into logical contiguous
areas. No swapping or paging is supported by the hardware microcode
for LPARs ... just the (relative) static partitioning of available
physical memory. LPARS started out sort of being a significant subset
of the mainframe virtual machine operating system support dropped
into the hardware of the mainframe.

mainframe logical partition getting eal5 certification:
http://www-1.ibm.com/servers/eserver/zseries/security/eal5_ac.html

LPAR support even has extended to non-mainframes:
http://www-1.ibm.com/servers/eserver/iseries/lpar/
http://www-1.ibm.com/servers/eserver/pseries/lpar/
http://www-1.ibm.com/servers/eserver/pseries/lpar/faq_2.html

lots of past posts mentioning LPARs:
http://www.garlic.com/~lynn/98.html#45 Why can't more CPUs virtualize themselves?
http://www.garlic.com/~lynn/98.html#57 Reliability and SMPs
http://www.garlic.com/~lynn/99.html#191 Merced Processor Support at it again
http://www.garlic.com/~lynn/2000b.html#50 VM (not VMS or Virtual Machine, the IBM sort)
http://www.garlic.com/~lynn/2000b.html#51 VM (not VMS or Virtual Machine, the IBM sort)
http://www.garlic.com/~lynn/2000b.html#52 VM (not VMS or Virtual Machine, the IBM sort)
http://www.garlic.com/~lynn/2000b.html#61 VM (not VMS or Virtual Machine, the IBM sort)
http://www.garlic.com/~lynn/2000b.html#62 VM (not VMS or Virtual Machine, the IBM sort)
http://www.garlic.com/~lynn/2000c.html#8 IBM Linux
http://www.garlic.com/~lynn/2000c.html#50 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000c.html#68 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000c.html#76 Is a VAX a mainframe?
http://www.garlic.com/~lynn/2000f.html#78 TSS ancient history, was X86 ultimate CISC? designs)
http://www.garlic.com/~lynn/2000g.html#3 virtualizable 360, was TSS ancient history
http://www.garlic.com/~lynn/2000.html#8 Computer of the century
http://www.garlic.com/~lynn/2000.html#63 Mainframe operating systems
http://www.garlic.com/~lynn/2000.html#86 Ux's good points.
http://www.garlic.com/~lynn/2001b.html#72 Z/90, S/390, 370/ESA (slightly off topic)
http://www.garlic.com/~lynn/2001d.html#67 Pentium 4 Prefetch engine?
http://www.garlic.com/~lynn/2001e.html#5 SIMTICS
http://www.garlic.com/~lynn/2001e.html#61 Estimate JCL overhead
http://www.garlic.com/~lynn/2001f.html#17 Accounting systems ... still in use? (Do we still share?)
http://www.garlic.com/~lynn/2001f.html#23 MERT Operating System & Microkernels
http://www.garlic.com/~lynn/2001h.html#2 Alpha:  an invitation to communicate
http://www.garlic.com/~lynn/2001h.html#33 D
http://www.garlic.com/~lynn/2001.html#34 Competitors to SABRE?
http://www.garlic.com/~lynn/2001l.html#24 mainframe question
http://www.garlic.com/~lynn/2001m.html#38 CMS under MVS
http://www.garlic.com/~lynn/2001n.html#26 Open Architectures ?
http://www.garlic.com/~lynn/2001n.html#31 Hercules etc. IBM not just missing a great opportunity...
http://www.garlic.com/~lynn/2001n.html#32 Hercules etc. IBM not just missing a great opportunity...
http://www.garlic.com/~lynn/2002b.html#44 PDP-10 Archive migration plan
http://www.garlic.com/~lynn/2002c.html#53 VAX, M68K complex instructions (was Re: Did Intel Bite Off More Than   It Can Chew?)
http://www.garlic.com/~lynn/2002d.html#31 2 questions: diag 68 and calling convention
http://www.garlic.com/~lynn/2002e.html#25 Crazy idea: has it been done?
http://www.garlic.com/~lynn/2002e.html#75 Computers in Science Fiction
http://www.garlic.com/~lynn/2002f.html#6 Blade architectures
http://www.garlic.com/~lynn/2002f.html#57 IBM competes with Sun w/new Chips
http://www.garlic.com/~lynn/2002n.html#6 Tweaking old computers?
http://www.garlic.com/~lynn/2002n.html#27 why does wait state exist?
http://www.garlic.com/~lynn/2002n.html#28 why does wait state exist?
http://www.garlic.com/~lynn/2002o.html#0 Home mainframes
http://www.garlic.com/~lynn/2002o.html#15 Home mainframes
http://www.garlic.com/~lynn/2002o.html#16 Home mainframes
http://www.garlic.com/~lynn/2002o.html#18 Everything you wanted to know about z900 from IBM
http://www.garlic.com/~lynn/2002p.html#4 Running z/VM 4.3 in LPAR & guest v-r or v=f
http://www.garlic.com/~lynn/2002p.html#40 Linux paging
http://www.garlic.com/~lynn/2002p.html#44 Linux paging
http://www.garlic.com/~lynn/2002p.html#54 Newbie: Two quesions about mainframes
http://www.garlic.com/~lynn/2002p.html#55 Running z/VM 4.3 in LPAR & guest v-r or v=f
http://www.garlic.com/~lynn/2002q.html#26 LISTSERV Discussion List For USS Questions?
http://www.garlic.com/~lynn/2003c.html#41 How much overhead is "running another MVS LPAR" ?
http://www.garlic.com/~lynn/2003f.html#56 ECPS:VM DISPx instructions
http://www.garlic.com/~lynn/2003.html#9 Mainframe System Programmer/Administrator market demand?
http://www.garlic.com/~lynn/2003.html#14 vax6k.openecs.org rebirth
http://www.garlic.com/~lynn/2003.html#15 vax6k.openecs.org rebirth
http://www.garlic.com/~lynn/2003.html#56 Wild hardware idea
http://www.garlic.com/~lynn/2003k.html#9 What is timesharing, anyway?
http://www.garlic.com/~lynn/2003l.html#12 Why are there few viruses for UNIX/Linux systems?
http://www.garlic.com/~lynn/2003l.html#41 Secure OS Thoughts
http://www.garlic.com/~lynn/2003m.html#32 SR 15,15 was: IEFBR14 Problems
http://www.garlic.com/~lynn/2003m.html#37 S/360 undocumented instructions?
http://www.garlic.com/~lynn/2003n.html#13 CPUs with microcode  ?
http://www.garlic.com/~lynn/2003n.html#29 Architect Mainframe system - books/guidenance
http://www.garlic.com/~lynn/2003o.html#52 Virtual Machine Concept
http://www.garlic.com/~lynn/2004b.html#58 Oldest running code
http://www.garlic.com/~lynn/2004c.html#4 OS Partitioning and security
http://www.garlic.com/~lynn/2004c.html#5 PSW Sampling
http://www.garlic.com/~lynn/2004d.html#6 Memory Affinity
http://www.garlic.com/~lynn/2004e.html#26 The attack of the killer mainframes
http://www.garlic.com/~lynn/2004e.html#28 The attack of the killer mainframes
http://www.garlic.com/~lynn/2004f.html#47 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004g.html#15 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004k.html#37 Wars against bad things
http://www.garlic.com/~lynn/2004k.html#43 Vintage computers are better than modern crap !
http://www.garlic.com/~lynn/2004m.html#41 EAL5
http://www.garlic.com/~lynn/2004n.html#10 RISCs too close to hardware?
http://www.garlic.com/~lynn/2004o.html#13 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2004o.html#32 What system Release do you use... OS390? z/os? I'm a Vendor S
http://www.garlic.com/~lynn/2004q.html#18 PR/SM Dynamic Time Slice calculation
http://www.garlic.com/~lynn/2004q.html#72 IUCV in VM/CMS

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

[Lit.] Buffer overruns

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: [Lit.] Buffer overruns
Newsgroups: sci.crypt,comp.security.unix
Date: Thu, 20 Jan 2005 20:36:30 -0700

daw@taverner.cs.berkeley.edu (David Wagner) writes:

You don't need hardware support to build capability-based systems.
There are modern systems that use language-based mechanisms instead
of hardware support.  My favorite example is E.
http://www.erights.org/

tymshare had done gnosis on mainframe 370. when m/d bought tymshare,
there was a spin-off company called keylogic and gnosis became keykos.

in the tymshare version, i estimated possibly 30 percent of total
pathlength was devoted to accounting ... aka was time-sharing service
bureau and they were looking at platform to deliver 3rd party
applications and provide (relatively) accurate charge backs to the
originators (in addition to partitioning and isoloation)

in the keykos incarnation ... the fine-grain accounting was taken out
and at one point they claimed ability to do higher transaction
efficiencies than TPF (specialized transaction operating system that
grew up from the airline control program ... also now used for major
financial transaction systems) on the same exact hardware.

since then there has been a microprocessor variety done called eros
that claims designed for EAL7 evaluation.

some current keykos references:
http://www.cis.upenn.edu/~KeyKOS/
http://www.agorics.com/Library/keykosindex.html

small preface from above:

This documentation describes the design and implementation of the
KeyKOS system. Initially developed at Tymshare, Inc., it was deployed
in production in 1981 as a secure server processing credit card
transactions while simultaneously supporting other
applications. Agorics has licensed this system and the associated
patents, and utilizes the fundamental ideas and technology in our
ebusiness solutions.

some current eros references:
http://www.cis.upenn.edu/~eros/
http://www.eros-os.org/

small disclaimer ... i was never directly associated with tymshare
and/or gnosis ... however i was brought in by m/d to do gnosis audit
prelude to the spinoff.

random past posts about (high assurance) time-sharing from the
60s, 70s, and into the 80s.
http://www.garlic.com/~lynn/subtopic.html#timeshare

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

[Lit.] Buffer overruns

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: [Lit.] Buffer overruns
Newsgroups: sci.crypt,comp.security.unix
Date: Thu, 20 Jan 2005 20:56:11 -0700

and, erights references keykos:
http://www.erights.org/history/keykos.html

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

Relocating application architecture and compiler support

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Relocating application architecture and compiler support
Newsgroups: comp.arch,comp.arch.embedded,alt.folklore.computers
Date: Fri, 21 Jan 2005 13:25:05 -0700

glen herrmannsfeldt writes:

This reminds me of the way Macintosh OS used to work.  (Does it
still do that?)  Fortunately I never wrote any low level Mac code,
but you had to be careful when things could be relocated, and not
store addresses across system calls that could move things around.

In the code above, you can't move things around between the AR and
the BALR.  The original mac didn't do preemptive multitasking, so
the user program always knew when things could move and when they
couldn't.

On the other hand, for a system like 680x0 with separate address and
data registers, maybe it isn't so hard.

it turns out that this is slightly different operation ... i (re)wrote
the displatcher, scheduler, page replacement, etc for cp/67 ... a lot
of it as undergraduate ... which was shipped in the standard product.
a lot of this was dropped in the morphing of cp/67 into vm/370 ... but
I got to put it (and a lot of other stuff) back in when i did
the resource manager for vm/370
http://www.garlic.com/~lynn/subtopic.html#fairshare
http://www.garlic.com/~lynn/subtopic.html#wsclock

because cp/67 (and vm/370) had virtual memory support ... each user
had their own virtual address space ... where pages could be brought
in and out of real storage at arbitrary real addresses.

the problem i had in the early 70s with location independent code ...
was that i wanted to be able to page-map applications to files on
disks ... and that multiple different virtual address spaces could
share the same exact (r/o) page-mapped information.

the problem with the standard os/360 model was that when executable
files out on disk were mapped into memory (virtual or real), the
program loader had to run thru arbritrary locations in the executable
image ... swizzling arbritrary address constants into different values
(randomly spread thruout the executable image).

as a result, it wasn't just a simple matter of page mapping an
executable image file (out on disk) into a virtual address space
... there was still all this address constant swizzling that had to be
done before the program could actually start execution. Furthermore,
the default was to touch every possible page that potentially
contained an address constant (that concievably might be used
... whether it actually was used or not) and do the appropriate
swizzling operation. And even further complicating the process was
that the swizzling operation went on within the specific virtual
address space that had just mapped the executable image.

So the swizzling operation that would go on in each virtual address
space ... pre-touched and changed an arbritrary number of virtual
pages (whether the actually application execution would touch those
specific pages or not) ... as well as making the pages chnaged
... defeating the ability to have the program image mapped into r/o
shared segments that were possibly common across a large number of
different address spaces. The issue that i was trying to address
wasn't what might be in the registers of each individual process
context in each virtual address space .... it was trying to make the
physical executable storage image of the application r/o shared
concurrently across a large number of different address spaces.  Any
modification required on the contents of that executable image,
defeated the ability to have it r/o shared concurrently across a large
number of different address spaces (as well as possibly prefetching
and changing pages that might never actually be used).

So that was the first problem.

A subset of the relocating shared segment implemention (that I had
done in the early 70s) was picked up by the product group and released
under the feature name as DCSS (DisContiguous Shared Segments). I had
done a page mapped file system along with the extended shared segment
support ... so that it was relatively straight-forward to page map
objects in the file system into virtual address spaces. The page
mapped file system wasn't part of the subset of stuff that was picked
up for DCSS. random posts on the page mapped file system work
http://www.garlic.com/~lynn/subtopic.html#mmap

They addressed the address constant swizzling problem by defining
globally unique system addresses for every application that would
reside in predefined virtual memory segments; loading the application
at that predefined virtual memory location and saving the virtual
address space image to a reserved portion of the system-wide paging
system (in part because they had failed to pick up the page mapped
filesystem enhancements).

So DCSS had a new kind of system command that would map a portion
of a virtual address space to a presaved application image (and
specify things like shared segments, etc).

So there were several limitations ... one it required system wide
coordination of the presaved applications as well as system privileges
to setup stuff (i.e. individual department couldn't enable their own
private applications).

A large installation would have more applications defined in this
infrastructure than could fit in a single 16mbyte virtual address
space ... and as a result, there had to be careful management of
applications that were assigned conflicting predefined, preswizzled
virtual addresses. While no single user was likely to try an map all
possible applications into a single address space at the same moment
... it was possible that a single user might need to map an arbritrary
combination of applications (in total less than 16mbytes), some of
which may have conflicting, pre-assigned and swizzled virtual address
images. As systems got bigger with wider variety of users and
applications, the problem of pre-swizzled virtual application images
with conflicting virtual address locations increased.

So the next solution was to have multiple pre-swizzled application
images defined at multiple different virtual address location. Users
would decide on the combination of page image applications and
libraries that needed to have concurrently loaded ... and try and find
some possible combination of the multiple different images of each
application that could comfortably co-exist in the same address space.

The original implementation that i had done from the ealy 70s ...  had
allowed page mapping arbitrary files as virtual address apace images
at arbitrary virtual address locations .... w/o needing to swizzle
address constants embedded in those page mapped images ...
in part because I had both done a lot of work on allowing address
location independent executable images
http://www.garlic.com/~lynn/subtopic.html#adcon
as well as page mapped filesystem enhancements
http://www.garlic.com/~lynn/subtopic.html#mmap

and furthermore that an executable image could occupy a read-only shared
segment ... were the same exact same pages were mapped concurrently
into multiple different virtual address spaces ... at possibly
different virtual addresses.

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

Relocating application architecture and compiler support

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Relocating application architecture and compiler support
Newsgroups: comp.arch,comp.arch.embedded,alt.folklore.computers
Date: Fri, 21 Jan 2005 14:49:09 -0700

so tss/360 had page mapped filesystem as standard and an objective
that a portion of virtual address space could be mapped to the
executable image out in the filesystem ... and that the mapping
process didn't have to track thru arbritrary virtual pages of that
executable image ... swizzling address constants. The system could do
the mapping and start program execution (almost) immedately ...
possibly w/o having to prefetch any of the executable image.

furthermore, if other address spaces were already sharing that
executable image on a r/o basis ... the mapping process would just
setup the segments so the different address spaces utilized the same
virtual pages.

so tss/360 had system wide convention ... assembler, applications,
compilers, etc ... that positioned any address constants that needed
swizzling separately from the executable image. This separate table of
address constants needing swizzling would be prefetched (as part of
mapping the executable file to the virtual address space) and the
necessary swizzle of address constants could be done in a private area
for each specific virtual address space. There then were system wide
conventions on how executable code accessed the table of (swizzled)
address constants .... the executable code image could be exactly the
same for all virtual address spaces ...  and in fact, the same exact
executable image could be the same exact virtual pages (using shared
segments) .... but the swizzled address constants would be located in
an (tss/360 system-wide convention) area separate from the executable
program image.

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

Factoring problem, solved

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Factoring problem, solved
Newsgroups: sci.crypt,sci.math
Date: Fri, 21 Jan 2005 15:48:19 -0700

Christian Bau writes:

It took me a while to realise, but what a lottery does is selling hope
at a relatively cheap price. You don't pay for the chance of winning,
you pay for the hope.

a lot of the gambling operations claim payouts of 95% or better.

state lottery may have a payout of 80% after their (direct) take
(education or whatever, gov. bureaucracy administrative overhead, etc)

so lets say a community starts with $1m and it is all played on
lottery each week.

first week, state keeps $200k and pays out $800k. however a good
portion of that $800 payout is claimed to be subject to fed. & state
income tax ... say another $300k the gov. also gets because of tax
law. so at the end of the first week the community may actually only
retain $500k.

second week, the community plays the remaining $500k, the state keeps
$100k, and pays out $400k. Much of that $400k is also subject to
income taxes, state & feds get another $150k ... leaving $250k to the
community.

third week, the community plays the remaining $250k, the state keeps
$50k, and pays out $200k. Much of that $200k is also subject to income
taxes, state & fed get another $75k ... leaving $125k.

the gimmick is that not only does the gov. take the 20% off the top
... but because of the way the tax laws are written the pay-offs are
taxed. You do get to subtract your purchases of lottery tickets from
winnings ... but it is in the govs. interest to have (few) big payoffs
where the winnings are also subject to big taxes. With really big
payoffs, the weekly churn can mean the gov. takes closer to 50% (each
week).

w/o fresh infusion of funds every week, at closer to 50% gov.
retention on gov. lotteries ... the gov(s). can quickly accumulate
most of the money in play.

i've seen slot machines claim 98% or better payout. their gimmick is
that they can also eventually accumulate all the money if all the
players keep repeatedly playing the same money (at 1% retention on
each round ... you just need to have a lot larger number of rounds
... compared to weekly lottery at closer to 50% retention, the amount
they directly keep plus the amount they may siphon off on each round
because of tax laws).

slots can also be purely the entertainment of playing.

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

Relocating application architecture and compiler support

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Relocating application architecture and compiler support
Newsgroups: comp.arch,comp.arch.embedded,alt.folklore.computers
Date: Fri, 21 Jan 2005 16:29:42 -0700

glen herrmannsfeldt writes:

But there is one thing that OS/360 does easily that is hard in other
systems, which is what the LINK macro does.  To take another
program, load it into the same address space, execute it (with the
original still addressable) and then return.

I remember TOPS-10, where each program was loaded with virtual
origin of 0.  There was a system for sending files to the print
queue which involved writing the entire address space to disk,
running the QUEUE program with an option to execute a program when
it was done, which would then reload and continue on.

Any system with a fixed load point can't have two programs in the
same address space at the same time.

In the OS/360 case, besides doing LINK, many routines, especially
access methods, were directly addressable somewhere in system space.
Now, there are systems which reserve parts of the address space for
system and parts for user, but that doesn't help LINK.

basically you could do link-like function in both os/360 as well as
tss/360. the primary difference was that os/360 had to read the
executable file image into memory and then run the address constant
swizzle against that were randomly sprinkled thruout the execution
image.

in the tss/360 scenario ... you just had to memory map some portion of
the virtual address space to the executable file image on disk (and
let the paging operation fetch the pages as needed) ... and all the
address constants needing swizzling were kept in a different
structure.

os/360 had a single real address space orientation so that it was
possible for multiple different processes to share the same executable
image because they all shared the same (single, real) address space.

tss/360 had multiple virtual address spaces .... and for multiple
different processes to share the same exact executable copy ... it
relied on the shared segment infrastructure.

in the os/360 scenario, all program loading was to a unique real
address ... since all processes shared the same, single real address
space (there was no chance for program address conflict ... since each
program could be assigned a unique real address as it was read into
memory).

in the tss/360 scenario, different processes might load & populate
their own virtual address space in difference sequences
... potentially creating address assignment conflict if there was a
requirement that each application have identically assigned virtual
address across all virtual address spaces.

in the os/360 scenario ... if you had two different processes,
the first LINKed app1, then app2, then app3, and finally app4 and
the second LINKed app2, then app4, then app3, and finally app1 ...
it all fell out in the wash since there was a single global
real address space.

a difference between the os/360 and tss/360 operation, is that os/360
allowed all the address constants (needing position location
swizzling) to be randomly sprinkled thruout the executable
image. tss/360 collected address constants (needing swizzling) into a
different structure.

both could do dynamic process location specific binding at program
load time.  however, in the tss/360 scenario ... different processes
could share the same exact executable image at different address
locations ... because the executable image was a separate structure
from the structure of address constants (that required location
specific swizzling).

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

[Lit.] Buffer overruns

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: [Lit.] Buffer overruns
Newsgroups: sci.crypt,comp.security.unix
Date: Fri, 21 Jan 2005 17:58:08 -0700

"Douglas A. Gwyn" writes:

I didn't say you did.  I said it was a shame that there isn't more
support for capas in hardware.  To build a really hackerproof system
one needs to lock it down tight all the way down to the lowest
accessible level.

a lot of cisc is business as usual.

future system (FS) was going to be a super-duper advanced architecture
with everybody's favorite feature built in ... including all sorts of
integrity and capability stuff.

i didn't make myself popular with the FS crowd since I was claiming
that we had some stuff as good or better currently running on more
traditional hardware ... than some of the stuff being designed for FS.

FS was eventually killed ... one of the nails in the coffin was the
calculation was that if a FS machine was built from the very fastest
370/195 technology then available ... that all the hardware layers
would have some number of application at about the same thruput as
existing 370/145 (possibly a 30:1 slowdown) ...  lots of post postings
on FS
http://www.garlic.com/~lynn/subtopic.html#futuresys

the other problem that I gave FS was security for their documentation.
There had been an incident where highly sensitive corporate paper
documents had been copied and leaked to the press. This led to an
investigation and all corporate copying machines retrofitted with
transparent serial numbers on the glass that would show up on every
copied page (similar but different to current stuff about every laser
printer having a unique fingerprint). Anyway the FS documents were
considered even more sensitive ... so there was going to be as little
paper as possible ... mostly softcopy restricted to very secure
systems. They made the mistake of saying that even if I was in the
room with the computer, i couldn't gain access to the documents. It
actually took less than five minutes.

part of the observation was that the technology base we were using was
being deployed in commercial time-sharing service bureaus with fairly
high level of integrity and assurance (a lot of customers in the
financial industry ... with concurrent customers that might even be
fierce competitors). including was the work-horse system for tymshare
and numerous others
http://www.garlic.com/~lynn/subtopic.html#timeshare

and few of these systems experienced any of the exploits and
vulnerabilities commoningly seen today. I've periodically joked that I
was asked in the 60s to write code to address security issues that
aren't even currently being considered in today's environment (because
there are so many significantly more serious security, exploit, and
vulnerability problems about).

an example was a online time-sharing system we had in cambridge in the
early 70s ... there was online access by MIT, Harvard, BU and other
students in the boston area ... as well as online access by people
from corporate hdqtrs doing data processing on corporate information
at the most highest sensitivity level. There were no outside breaches
... there were a couple denial of service events that were quickly
corrected.

i've periodically commented that major early RISC activity (801) in
the 70s could be considered a reaction to the failure and demise of FS
.... going to almost the opposite extreme in terms of hardware
complexity. lots of past 801, romp, rios, risc, etc. posts
http://www.garlic.com/~lynn/subtopic.html#801

and that anything that was being planned for FS could be done better
in sophisticated software on simplified hardware.

the folklore is that some number of the FS crowd did migrate to
Rochester where they recreated FS on a much smaller scale called
system/38. The system/38 evolved into cisc as/400 ... and eventually
as/400 migrated to risc (power/pc). So it has sort of come
full-circle. I claim that at least some of the genesis for RISC came
from the failure of FS ... 801, ROMP, RIOS, power, power/pc, etc. Some
number of the FS survivors went to Rochester and created small scale
FS with very customized hardware called the S/38, which evolved into
CISC as/400 ... but eventually morphed into RISC as/400 on power/pc.

Somewhat the original 801 was that you could raise the lowest
accessable level for application software and provide the necessary
lockdown as part of sophisticated software layer ... w/o needing the
expense of specialized hardware (somewhat epitomized by FS). In some
sense that is the current RISC-based as/400.

The 801 programming language was PL.8 (pl1 subset) with CPr as
operating system. The original 801 had no hardware protection
domain. The PL.8 compiler would only generate correct application code
and the loader/binder would validate that only valid generated PL.8
code was being loaded. Once such an application was running it could
directly access all software and hardware facilities (correctly) w/o
necessity for kernel calls to cross protection domains.

When it was decided to retarget an 801/RISC processor to unix
workstation market, more traditional supervisor/appilcation
(kernel/non-kernel) protection mode had to be added to the hardware.

part of the point was that it is possible to build high integrity (as
well as high-thruput) infrastructures w/o lots of hardware reliance
... if the overall structure is otherwise sound.

one such demonstration was/is the keykos system ... runs on standard
370 architecture ... with some number of the characteristics that were
being claimed for FS.

Some topic drift ... much of the folklore has major motivation for FS
were the plug-compatible controllers .... FS would provide much higher
degree and complex infrastructure integration making plug-compatible
controllers an extremely difficult proposition.

as an undergraduate in the 60s, one of the projects that i got to work
on was university plug compatible controller that was written up as
one of the genesis of the public compatible controller business (which
created a major motivation for FS). mosc past posts on early
plug compatible controller project
http://www.garlic.com/~lynn/subtopic.html#360pcm

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

Relocating application architecture and compiler support

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Relocating application architecture and compiler support
Newsgroups: comp.arch,comp.arch.embedded,alt.folklore.computers
Date: Fri, 21 Jan 2005 19:39:56 -0700

Peter Flass writes:

So why was TSS considered so slow?  (not that OS/360 was any ball of
speed).

lots of reasons ... long path lengths ... over complex algorithms
... bloated code size.

lets say you had os/360 (or cms) environment that did program load
... it could queue up a single i/o that read application into memory
in multiple 64k chucks ... all batched together.

tss/360 could have a large compiler laid out as 1mbyte memory mapped
file ... do a memory mapping for 256 4k pages ... and then possibly
individually page fault each 4k page one at a time. To some extent
they got over enamored with concept of one-level store and paging and
lost the fact that the purity of the concept could significantly
increase the latency if all transfers had to be serialized 4k bytes at
a time (as opposed to doing program loading batching in larger
transfer units).

kernel was really large ... tss/360 supposedly was going to have
target of 512k 360/67 ... but quite quickly grew to minimum 768k
storage because of bloated fixed kernel. at one point there was a
statement about a set of benchmarks down on a 1mbyte 360/67
uniprocessor and on a 2mbyte 360/67 two processor machine ... with the
2mbyte/2processor having 3.8 times the thruput of the single processor
benchmark. the official coment was (while the uniprocessor system was
really slow), the two processor benchmark having 3.8 times the thruput
of the single processor benchmark demonstrated how advanced the
tss/360 multiprocessor algorithms were (getting almost four times the
thruput with only twice the hardware). the actual explanation was that
the kernel was so bloated that it could hardly fit in 1mbyte
configuration .... and that in the 2mbyte configuration there was
almost enuf memory (not in use by the kernel) for running
applications.

benchmark at the university on 768k 360/67 running tss/360 .. i
believe prerelease 0.68 with four emulated users doing mix-mode
fortran edit, compile and execute ... had multi-second response for
trivial program edit line input. at the same time, on the same
hardware with cp/67 running same mix-mode fortran edit, compile and
execute had subsecond response for trivial edit line input .... but
running 30 conccurent cms users ... compared to 4 tss users (although
i had already done a lot of cp/67 performance enhancements).

there was folklore that when tss/360 was decommited and the
development group reduced from 1200 people to possibly 20 ... that a
single person now had responsibility for the tss/360 scheduler and a
large number of other modules. supposedly the person discovered that
on a pass thru the kernel ... every involved kernel module was
repeatedly calling the scheduler ... when it turn out that it was only
necessary to call the scheduler once per kernel call (rather than
every module calling the scheduler resulting in multiple scheduler
calls per kernel call). fixing that is claimed to have eliminated a
million(?) instructions per kernel call.

at some point in the tss/370 life ... it had been relatively stable
for a long time ... with a lot work over the years on performance
tweaking ... they claimed that they got the total pathlength to handle
page fault (page fault, page replacement select, schedule page read,
task switch, page read complete, task switch, etc) down to maybe five
times better than MVS ... but still five times longer than my
pathlength for equivalent sequence in vm/370.

it was in this era (late 70s) that they did the unix project for at&t
... where a kernel semantics interface was built on low-level tss/370
kernel function to support high-level unix environment. i believe this
tss/370 environment for unix was called ssup.

one of the early tss/360 features that i gave them trouble about was
the whole thing about interactive vs-a-vs batch. early 360/67 had 2301
"drum" for limited amount of high-speed paging space and the rest was
2311 (very slow) disks. the scenario went something like ... if some
finished a line in edit and hit return (on 2741) ... tss kernel would
recognize it as interactive and pull the pages that the task had been
using the previous time from 2311 into memory and then write them all
out to 2301 ... once that was done it would start the task ... which
would allow it to page fault the pages back into memory from the 2301.
when the trivial interactive task went into wait (for more terminal
input), the kernel would pull all of the tasks pages off the 2301 back
into memory and move them to 2311. This dragging of pages off 2311 int
memory and out to 2301 and then dragging the pages off 2301 into
memory and out to 2311 would occur regardless of whether there was any
contention for either 2301 space or real memory space. It was a neat,
fancy algorithm and they would do it everytime ... whether it was
necessary or not ... just because it was so neat(?).

... there is a lot more ... but that should be enuf for the moment.

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

something like a CTC on a PC

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: something like a CTC on a PC
Newsgroups: alt.folklore.computers
Date: Sun, 23 Jan 2005 08:57:38 -0700

CBFalconer writes:

He's talking about the language used to implement the comm, and
peripherally about the ugly things done to that language by failure
to follow standards.  If the implementors had followed the standard
Pascal would be popular today.  As it is they tied their versions to
hardware and OSs that are, to all practical purposes, gone.

the standard pascals tended to be somewhat limited. i was once asked
to port a 50k-60k line vs/pascal application to another platform
"standard" pascal. the vs/pascal extension had to be remapped to
relatively standard pascal ... which could be annoying but not
difficult. the problem was that the target pascal had never appeared
to ever been used for any serious application of any size ... and what
is worse, the vendor had outsourced the support to an organization 12
timezones away. nearly every day there was another bug/problem
... while i could go talk to the local people ...  it still took time
to cycle thru the outsourced process.

vs/pascal originaly had been done at los gatos lab (bldg.29) for
mainframe by P & W.  A backend was done for vs/pascal that also
supported aix & risc processors.  W went on to be vp of software
development at MIPS and later was general manager of the business unit
responsible for java. P went to metaware in santa cruz.

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

something like a CTC on a PC

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: something like a CTC on a PC
Newsgroups: alt.folklore.computers
Date: Sun, 23 Jan 2005 09:13:55 -0700

CBFalconer writes:

He's talking about the language used to implement the comm, and
peripherally about the ugly things done to that language by failure
to follow standards.  If the implementors had followed the standard
Pascal would be popular today.  As it is they tied their versions to
hardware and OSs that are, to all practical purposes, gone.

one might claim that C achieved critical mass and dominance over
pascal ... because of the penetration of unix and unix applications
... which representd a fairly significant and available C code base.

turbo pascal achieved some market use ... but it didn't extend down
thru the very core of the operating system (and I don't remember a
large number of operations doing any major projects with turbo pascal
... that also shipped the code as part of any product).

--
Anne & Lynn Wheeler | http://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, 23 Jan 2005 10:30:40 -0700

"John E. Hadstate" writes:

There was a study, somewhat dated now to be sure, that claimed that
an average programmer could produce 10 lines of bug-free code per
day.  Oddly, the number didn't seem to depend much on PL used.  In
other words, the study found that the programmer could produce 10
bug-free lines of assembler code, 10 lines of COBOL, 10 lines of C,
etc.  This supported an economic argument that since 10 lines of C
was believed to represent a greater quantity of useful computation
than 10 lines of assembler, C was to be preferred over assembler
code as a more cost-effective Systems Programming Language.

somewhat depends on code characteristics ... a lot of code there can
be a 10:1 difference between assembler and higher level language
... however, a lot of low level kernel programming ... that tends
towards a lot of conditional testing and conditional execution
... tends sometimes to close to 1:1.

in the early 70s, i wrote a PLI program to analyze assembler programs
... it created an abstract representation of the machine instructions
and the instruction sequence (& control flow).

one of the common failure modes in large assembler programs was
register content management (at least in mainframe assembler with 16
registers ... and conventions of both short-term as well as some
long-term register contents use). quite a few kernel failures from the
time were essentially use-before-set problems ... some atypical
control flow not establishing the register contents correctly before
subsequent use.

higher level programming languages have tended to do a much better job
of managing register content values ... and especially after early 80s
... also doing better job of recognizing things like use-before-set
problems.

there were however some assembler routines that could almost be
simpler than higher level PL. my early 70s programs attempted to take
the program abstraction and output higher level program
representation. Some highly optimized, compact kernel routines doing
various kinds of conditional testing and branch operations ... would
translate into very convoluted, nested if/then/else type structures
sometimes 10-15 (or even more) levels deep. It appeared that with enuf
incentive, low-level assembler "GOTO" programming can get extremely
inventive.

This made an impression on me ... since I had recently been to some
presentations .... that included GOTO-less programming and "super
programmer" (Harlen Mills).

--
Anne & Lynn Wheeler | http://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, 23 Jan 2005 14:54:38 -0700

to bring it back a little to buffer overruns (in C) ...  there were
enuf registers (16) so that environments could define conventions for
relatively long lived register contents (like address pointers)
... but not enuf registers that there wasn't frequently "overloading"
of (long-lived) register contents (i.e. the same register used for
multiple different purposes in the same application).

that condition as well as ambiguity about specific code paths possibly
not establishing required register content correctly before use
... led to some number of failures (using a register as an address
pointer when its current contents are from some arithmetic operation).

some number of register content failure modes were identical to
dangling pointer use failure modes ... so it could take some
additional investigation to distinrquish failures that failed to
establish register contents from establishing register contents with
dangling pointer.

however, there are some similarlities between mistakes with register
content management (in assembler) and the typical mistakes with
operations involving buffer lengths in typical C language
environments. At least in the assembler case, there was some studies
that showed the greater the "distance" between typical register
content value establishiment and content use ... the greater the
probability of human mistake, I know of no similar study showing the
"distance" between establishment of buffers in C and subsequent use
increases the probability of buffer length mistakes (although I could
conjecture it to be possible).

The "distance" was typically cognitive thinking process ... between
the time that the programmer had to think about putting a value in a
register ... and thinking about the use of that register contents.
Such cognitive distances were further aggravated if you had 15 year
code and somebody new was doing maintenance ... if there was a large
cognitive distance ... new maitenance might even miss the requirement
for register content establishment.

The funny thing about these assembler environments was that there were
very few buffer length problems. At least the environments I dealt
with had established conventions that buffer lengths were carried with
the buffer .... so programming convention was typically pick up the
length at the same point any use of the buffer was made (very small
cognitive distance between establishing the length and referencing any
use involving the length). C language conventions tends to require
that the programmer is cognizant of each buffer length ... where the
original length value establishment may be widely separated from where
there are references involving the use of the length.

for some other topic drift related to assembler analysis and abstract
representation in higher level language ... while there is fairly
direct correspondance in counter loops ... (at least) 370 assembler
could have complex 3-4 value conditional operations ... while a lot of
higher level language tends to be true/false conditional logic.

370 assembler provided for two-bit condition code setting allowing for
four possible values. lots of instructions involving comparisons
resulted in at least setting of three possible conditions. compares
(arithmetic and logical) were less-than, equal, and
greater-than. bit-twiddling operations tended to be all zero, all
ones, and mixed. arithmetic operations were greater-than-zero, zero,
less-than-zero.

Branch instructions were four bits ...  one corresponding to each
possible condition code value (conditional branches could specify any
combination of possible condition code).

complex assembler code (especially kernel optimized code) could easily
have a test condition followed (effectively) by three different code
paths) ... regularly encountered things like:

     test-condition
     branch-condition equal/zero
     branch-condition high/ones
     * fall-thru for low/mixed

and sometimes there were even cases of full four-value logic code
paths. somewhat the difference between two-value, true/false logic
paradigm ... and three or four value logic paradigm.

and if you aren't tired of topic drift ... some past posts on
three-value logic ...
http://www.garlic.com/~lynn/2003g.html#40 How to cope with missing values - NULLS?
http://www.garlic.com/~lynn/2004f.html#2 Quote of the Week

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

CAS and LL/SC

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: CAS and LL/SC
Newsgroups: comp.arch
Date: Sun, 23 Jan 2005 15:05:41 -0700

Bernd Paysan writes:

I started with 1MB, and worked quite ok for years, until I upgraded
to 4MB (Atari ST). When I switched over to a Linux 486 PC, 16 MB
seemed to be "plenty". Well, not that plenty, but the 64MB of the
next (Pentium) PC could do all the stuff at ease. Except GIMP, but I
was quite confident that the 256MB of the Athlon PC would be more
than sufficient. Now I have a higher resolution scanner, and 1GB
(with an Athlon64) seems to be enough.

All I can see is that Moore's law is slow enough that the increasing
amount of data can follow. I enjoy having several undo levels on
high resolution pictures.

i started with 64k "personal computer" ... the university normally
shutdown the computing center over the weekend (from 8am sat. to 8am
mon) ... but they gave me a key to the machine room and I could use
the 360/30 for 48hrs straight w/o any interruption.

it is how almost 40 years later and i've now got a 4gbyte (although
linux claims that there is only 3.5bytes) "personal computer". except
for the possible linux glitch, have effectively doubled the number of
address bits ... 2**16 to 2**32 in just under 40 years ... although
4gbytes may do me until it has been 40 years.

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

CAS and LL/SC

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: CAS and LL/SC
Newsgroups: comp.arch
Date: Mon, 24 Jan 2005 10:57:50 -0700

Andi Kleen writes:

It's a BIOS glitch, Linux is not to blame.

Directly below 4GB there is the PCI+AGP memory hole which is roughly
500MB. Your BIOS is not able to map the memory "around" the hole and
the memory sitting below the hole is lost. Linux cannot use it
because it can only use memory that the BIOS gives to it.

bios says

4gbyte memory
agp (defaulted) 128mb, only options 64mb, 128mb, & 256mb
primary graphics uses agp

i don't use 3d graphics, i changed bios agp from 128mb to 64mb and it
didn't make any difference, still shows 3.5gb (fedora fc3)

--
Anne & Lynn Wheeler | http://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, 24 Jan 2005 15:06:33 -0700

daw@taverner.cs.berkeley.edu (David Wagner) writes:

Right.  It's a shame that the entire standard C library is implemented
in an unreasonable way (it does exactly the wrong thing, by the above
criterion).  That may have something to do with why so many C programs
have buffer overruns.

linux magazine, feb. 2005, pg. 38, The Oldest Trick in the Book,
Understanding the buffer overflow exploit

... from above

According to NIST in the past 4 years, 871 buffer overflow
vulnerabilities were exploited, commprising about 20 percent
of all exploits

... snip

which is about the same percentage that I calculated from
the CVE database.

Article mentions that the exploit first gained widespread notoriety in
1988 with the Morris worm.

for some topic drift about bitnet email worm that predates the
internet worm by about a year:
http://www.garlic.com/~lynn/2004p.html#13
http://www.garlic.com/~lynn/2004p.html#16
http://www.garlic.com/~lynn/2004p.html#17
http://www.garlic.com/~lynn/2004p.html#21

note that the original mainframe TCP/IP stack had been implemented in
vs/pascal. It had some issues .... getting about 44kbytes/sec thruput
using 100 percent of a 3090 processor. I enhanced the stack with
RFC1044 support ... and in testing at cray research between cray and
4341-clone ... it was getting 1mbyte/sec using only a modest amount of
the 4341-clone processor. recent posting on the subject
http://www.garlic.com/~lynn/2005.html#51

collected posts mentioning rfc 1044 support
http://www.garlic.com/~lynn/subnetwork.html#1044

as an aside, I'm not aware of any buffer overflow exploits in this
implementation.

--
Anne & Lynn Wheeler | http://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, 24 Jan 2005 15:10:16 -0700

glen herrmannsfeldt writes:

Maybe because assembler programming requires more thought to get
things right, including more thought on the lengths and checks.

i don't think so ... it had register content management problems with
compareable frequency. one of the claimed advantages of using a higher
level language over assembler was that the higher level language took
over and automated the drudgery of register content management.

the issue wasn't so much assembler specifically ... it was in the
overall environment (that the assembler was used in) there was a
pervasive convention of carrying buffer length as part of the buffer.

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

The Mac is like a modern day Betamax

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The Mac is like a modern day Betamax
Newsgroups: alt.folklore.computers
Date: Mon, 24 Jan 2005 23:26:19 -0700

pc writes:

on my Windows 2K, Cyberlink PowerDVD seems to.  i'm guessing it has
something to do with video memory, so maybe it's not a great example
but i doubt Mac's have same problem (the only one i ever used was the
original Lisa and i gather Macs have some BSD code in them now).  (in
windows, i go shift-click to get the "run-as" option.) a couple of
other programs too, but i can't remember which ones at the moment.

mach; used for NeXT and the current mac/os ... microkernel developed
at cmu. a number of platforms used mach at one time or another. other
things by cmu in that period were the andrew filesystem, andrew
widgets, camelot transaction system, etc.

another major unix-like was the distributed Locus system out of
UCLA. Locus was the basis for aix/370 and aix/ps2.

DCE work had some amount of input/influence from both andrew
filesystem and locus (as well as apollo, dec, ibm's DFS, etc).

some random past mach posts
http://www.garlic.com/~lynn/2000e.html#27 OCF, PC/SC and GOP
http://www.garlic.com/~lynn/2001b.html#14 IBM's announcement on RVAs
http://www.garlic.com/~lynn/2001f.html#23 MERT Operating System & Microkernels
http://www.garlic.com/~lynn/2001n.html#35 cc SMP
http://www.garlic.com/~lynn/2002i.html#73 Unisys A11 worth keeping?
http://www.garlic.com/~lynn/2003c.html#45 Early attempts at console humor?
http://www.garlic.com/~lynn/2003e.html#25 A Speculative question
http://www.garlic.com/~lynn/2003e.html#33 A Speculative question
http://www.garlic.com/~lynn/2003.html#46 Horror stories: high system call overhead
http://www.garlic.com/~lynn/2003.html#50 Origin of Kerberos
http://www.garlic.com/~lynn/2003i.html#66 TGV in the USA?
http://www.garlic.com/~lynn/2003j.html#72 Microkernels are not "all or nothing". Re: Multics Concepts For
http://www.garlic.com/~lynn/2004c.html#53 defination of terms: "Application Server" vs. "Transaction Server"
http://www.garlic.com/~lynn/2004k.html#50 Xah Lee's Unixism

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

360 DIAGNOSE

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 360 DIAGNOSE
Newsgroups: alt.folklore.computers
Date: Tue, 25 Jan 2005 13:00:01 -0700

pc writes:

i don't know why but i'm curious about the various uses people put the
360 DIAGNOSE instruction to.

a friend once told me of his New Zealand experience in the 60's, at
Uni-Lever i think, when the IBM reps ordered him not to use
DIAGNOSE. he refused and the dispute went all the way up to Lever's
chairman and IBM's boss for the south Pacific, if i've got it right.
settled in friend's favour on the grounds that customer is always
right.

i've forgotten what he was using it for, but it had nothing to do with
VM or CMS.

years later i worked at a place where most of the assembler developers
didn't know anything about MVS JCL.  all we used for testing was a
handful of TSO Clists and TSO TEST.  change control people took care
of everything else.  one of the interrupts was SVC 98, i think.  given
a 3270 world then, i thought it was pretty productive.

"real" diagnose tends to invoke machine specific microcode whose
operations aren't defined in the POP (aka the POP says something about
diagnose functions are defined as being model specific).

I had done a modification for CMS disk i/o while an undergraduate that
used a special CCW that encapsulated the whole seek/search/read-write
process in a single operation (minimizing a bunch of pathlength in
CCWTRANS) and was defined to be CC=1, CSW-STORED semantics (i.e.  lots
of asynchronous pathlength and processing was bypassed in both CMS and
CP). part of the reason in worked was that (both CP and) CMS formated
CKD disks into standardize format and effectively simulated
fixed-block architecture on CKD disks (so all disk CCW operations were
very uniform and regular). It cut about 90 percent of the pathlength
and overhead out of CMS disk i/o operations.

People at cambridge (primarily bob adair) were very emphatic about not
violating POP ... so the cms performance "enhancement" was remapped to
a (simulated) diagnose instruction ... under the architecture umbrella
that DIAGNOSE is defined as being model dependent ... and an artifical
"model" abstraction could be defined for a virtual machine machine
model. The semantics stayed pretty much the same ... unform channel
program that bypassed loads of generalized CCWTRANS process and that
it appeared as a synchronous operation (eliminating the asynchronous
processing overhead).

over the years, lots of liberties were taken to enhance and optimize
the cms virtual machine environment using the virtual machine
machine model diagnose interface.

this is not to say that there weren't things like service diagnostics
that were machine model specific that would invoke unique real
hardware operations that were embedded in the microcode of a specific
machine model (and not defined/specified in the principle of
operations).

misc. past postings about CKD disk/dasd
http://www.garlic.com/~lynn/subtopic.html#dasd

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

stranger than fiction

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: stranger than fiction
Newsgroups: alt.folklore.computers
Date: Tue, 25 Jan 2005 13:31:02 -0700

from the annuals of truth stranger than fiction ... i was interviewed
before xmas for a possible magazine article about garlic.com/~lynn
website and its mainframe historical observations (in large part
archived postings made to this news group over the years). I just took
a call from them now wanting to do a photoshoot for the article.
trouble is that other than screen and keyboard, there is very little
to take pictures of.

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

360POO

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 360POO
Newsgroups: alt.folklore.computers
Date: Tue, 25 Jan 2005 15:06:10 -0700

Rich Alderson writes:

Because these clunky PDFs are the result of scans to TIFF format
which are then bound into electronic codices to resemble the
originals (often rare); using OCR to make them into searchable text
is a different, far more time- consuming process.

Al Kossow does what he does out of the goodness of his heart, in his
spare time--and he has a real job.  Thank him for his good works,
and stop bitching!

note that the principle of ops was one of the major mainstream
documents (other than the cp and cms documents) that was put into cms
script softcopy form.

one of the original reasons was that the superset of the principle of
operations is the architecture "redbook" ... which has a lot more
stuff than what appears in the POP (possibly as much again as the pop
subset. they used script conditionals to control whether the redbook
would be generated or the principle of operations subset would be
generated.

i think you can tell the transition from the traditionally process
printed document to the cms script version by the diagram boxes. the
cms script version was printed on 1403 printer and didn't provide
solid horizontal lines. Later they got solid horizontal lines with the
3800 ... but in the 1403 printer period, the horizontal diagram lines
were not solid.

the original cms script was done at the science center with run-off
"dot" formating commands. After gml was invented at the science center
in 1969 ... cms script was enhanced to also provide processing support
for gml tags.

recent posts discussion 360 storage key operation referencing the
early 360 POPs (on bitsavers) and more recent pops (from an earlier
part of the buffer overrun thread):
http://www.garlic.com/~lynn/2005.html#5 {Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005.html#6 {Lit.] Buffer overruns

part of this was instigated by the AMD reference about provide
no-execute support as part of buffer overflow exploit countermeasure
(i.e. it doesn't eliminate the buffer overflow ... but it prevents an
attacker from utilizing the buffer overflow in performing certain
kinds of system exploits)
http://www.garlic.com/~lynn/2005.html#1 {Lit.] Buffer overruns

misc. science center posts
http://www.garlic.com/~lynn/subtopic.html#545tech

misc. gml (sgml, html, xml, etc) posts
http://www.garlic.com/~lynn/subtopic.html#sgml

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

CAS and LL/SC

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: CAS and LL/SC
Newsgroups: comp.arch
Date: Tue, 25 Jan 2005 15:38:15 -0700

Bernd Paysan writes:

Yes, the 'channel' controllers from the zSeries date back to the
/360 or /370 (Lynn Wheeler might know better). The mainframe designs
from back then have ideas that the microprocessor folks have
forgotten and are now forced to reimplement step by
step. Virtualization is one of them (the /360 wasn't, but the /370
was). Those who forget history have to repeat it.

The CDC6600 had a similar concept.

channel programs were in 360 ... and there were channel processors
that executed channel programs. channel programs were composed of
sequence of channel command words (8 byte instructions) that were
executed one at a time by the channel processor. most 360s were
microcoded and many of the channel processors were integrated with the
same engine running the 360 instructions ... just a different block of
microcode.

i/o supervisor would store the address of the start of a channel
program in the CAW (channel address word) and issue a start I/O (SIO)
to the specific channel number.

the faster 360s (360/65) had separate boxes that executed channel
programs (as opposed to channel processing being integrated on the
same engine with the instruction processor)

cp67 virtual machine support running on 360/67 (basically 360/65 with
virtual memory hardware) has had the problems. channel programs are
defined as specifying real addresses. Virtual machine support required
intercepting the SIO, analysing the virtual machines I/O sequence,
making a copy of it ... and (at least) translating all of the virtual
machine specified "address" to the "real" machine address. If the I/O
operation involved a transfer that cross a page boundary and the pages
weren't contiguous ... then the copied channel program had to also
specify multiple non-contiguous addresses. Furthermore the virtual
pages had to be pined/fixed in real memory (at their translated
address) for the duration of the i/o operation.

this scenario has continued ... for all the virtual memory operating
systems. in the initial prototype of the batch, real-memory os/360
operating system to 370 virtual storage ... a copy of CP67's ccw
translation was grafted onto the side of the operating system ...
since it had to do similar virtual address to real address
translation, pin/fixing of virtual pages, etc.

part of the paradigm is that almost all i/o operations tended to
always be direct .... the normal paradigm as been direct asynchronous
i/o operation (no buffer moves needed), even at the application level
(as opposed to operating system creating construct of transfers going
on behind the scenes).

the 370/158 was integrated channels. the next generation was 303x.
they took a 370/158 and eliminated the 370 microcode ... just leaving
the integrated channel migrated and renamed it the 303x channel
director. 370/158s and 370/168s were then repackaged as 3031 and 3032
using the 303x channel director (in some sense 3031 was a two
processor, smp 158 ... except instead of two processors with both
integrated channel microcode and 370 microcode ... one processor just
had the channel microcode and the other just had the 370 microcode).
The 3033 started out being 370/168 circuit diagram remapped to faster
chip technology ... supposedly resulting in 20% faster processor than
168. During the cycle tho, there were additional stuff done ot the
3033 so that it eventually was about 50% faster than 168.

One of the issues in 370 with faster processors was the synchronous
hand-shake required by the SIO instruction between the processor
engine and outboard channel engine. The other problem was the
significant impact on cache hit ratios from asynchronous interrupts.
"XA", besides introducing 31bit virtual addressing ... also introduced
a new I/O processing paradigm ... where new processing engine could
handle much of the asynchronous crud involved with i/o ... and present
a much more pleasant queued and low-overhead paradigm to the main
processor. The other thing it addresses was real-time I/O redrive.  In
the 360/370 paradigm ... when there was a queue of requests for a
drive, the processor got interrupted, processed the interrupt and
eventually got around to redriving the device from the queued
requests. The more pleasant queued interface allowed a external
real-time engine the capability of redriving queued requests. All
targeted at lowering the tight serialization between i/o operations
and the instruction engine.

There is now a subset of virtual machine support built into all the
mainframe processors called logical partitions. It has most of the
characteristics of the original cp67 ... but built into the hardware
microcode and supporting a limited number of concurrent virtual
machines (partitions). It has simplified the ccw translation process
because each partition's memory is contiguous and fixed in storage
i.e. simple base & bound rather than fragmented non-contiguous
pages.  The i/o subsystem can directly use the base&bound values
avoiding needing to make an on-the-fly copy of every channel program
and modify the storage addresses.

this is sort of high level overview ... a lot of the actual stuff are
the nits in the low level details.

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

Relocating application architecture and compiler support

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Relocating application architecture and compiler support
Newsgroups: comp.arch,comp.arch.embedded,alt.folklore.computers
Date: Tue, 25 Jan 2005 18:07:52 -0700

Edward Wolfgram writes:

Lynn's example is not relocateable to the level you are thinking-
that is, relocateable at an interrupt level.  Once execution starts,
virtual (not physical) memory addresses must stay put.

The relocatabilty you are talking about can be done, but it would be
enormously difficult and a PIA. It would mean that all memory
(address) references must be atomic.  E.g.

i had a very simple objective that the executable program image on
disk would be identical to the executable program image in virtual
memory and that the same executable program image could appear (using
virtual memory segment sharing) could appear concurrently in multiple
different virtual address spaces at potentially different virtual
addresses.

each active, executing context of that executable program image (in
360) could have location specific bindings (like addresses in
registers) ... but the storage image of the executable program would
not.

os/360 conventions peppered the program image with things called
relocatable address constants ... which would be swizzled to an
address/location specific value when the program was brought into real
storage (or mapped into virtual address space) before actual execution
began.

tss/360 accomplished the objective by collecting the relocatable
address constants (needing any swizzling) into a different structure
that could be private to a specific executable instance ... but wasn't
part of the instruction program image.

For the stuff i did, i made due with various programming hacks to
resolve things relative to content of some register .... and in 360,
it is possible to establish the specific register executable instance
contents with mechanisms like BALR reg,0.

this is somewhat analogous to different threads executing the same
exact code tending to have their private instance execution
environment .... even though the exact same common code is being
executed ,,,, and extending the private instance execution environment
to include instance specific location of the (same) executable code.

in both cp67 and vm370 (360, 370 and later), the virtual memory
relocation mechanism allowed placement of virtual storage pages at
randomly (and potentially varying) real storage locations
... transparent to the application.

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

Relocating application architecture and compiler support

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Relocating application architecture and compiler support
Newsgroups: comp.arch,comp.arch.embedded,alt.folklore.computers
Date: Tue, 25 Jan 2005 19:39:18 -0700

glen herrmannsfeldt writes:

Different objectives have been discussed in this thread, both
with and without S/370 style DAT.   If one wanted to do timesharing on
S/360 including relocating programs as they were swapped in and out,
something more complex would be required,
possibly including conventions on register use.

It was nice of S/370 to come along when it did to remove the
need for that problem.

note the original base/bound stuff that boeing used to do swapping of
contiguous memory ... may have been in the microcode of some number of
(360/50) machines possibly associated with emulation (1401, 7094, etc)
... as opposed to some custom microprograming that they had done.

it was possible to get custom microprogramming support on many of
these machines. I think it was Lincoln Labs may have originated the
search-list (SLT) instruction that was installed on some number of the
360/67s.

the boston programming center in support of the conversational
programming system (CPS) ... interactive PLI and BASIC that ran under
relative vanilla os/360 ... had done a custom RPQ microcode package
that could be had for 360/50 ... that was performance acceleration for
doing interpretive execution. I don't know the details of how CPS
handled swap-in/swap-out ... it is possible that they controlled a lot
more of program execution ... they could control the instruction image
not having embedded location specific information and knew what
registers in the private execution context needing swizzling when
swap-out/swap-in sequence didn't bring back to the same swap address.

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

M.I.T. SNA study team

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: M.I.T. SNA study team
Newsgroups: alt.folklore.computers
Date: Wed, 26 Jan 2005 09:30:35 -0700

i got a new toy that i'm just learning to use (especially trying to
cleanup the OCR bit) ... an epson 2480 flatbed scanner

note that the internal network was not SNA (or not SNA well into the
80s)
http://www.garlic.com/~lynn/subnetwork.html#internalnet

misc. past comments related to SNA, SAA, 3tier, etc
http://www.garlic.com/~lynn/subnetwork.html#3tier

There has been some folklore that the PU4/PU5 (sscp/ncp, 3705/vtam)
interface complexity was an outgrowth of the failure of fs
http://www.garlic.com/~lynn/subtopic.html#futuresys

which supposedly had a major objective of addressing the plug
compatible controller competition. there was some write-up that blames
a project that I worked on as an undergraduate for spawning the plug
compatible controller business (i.e. reverse engineered the 360
channel interface and built a channel interface card for an
Interdata/3 and the Interdata/3 programmed to emulate a mainframe
telecommunication controller):
http://www.garlic.com/~lynn/subtopic.html#360pcm

the paper is copy made on an internal corporate copier ... it has one
of the copier IDs on the corner of each page. recent post that
mentions the incident that lead to retrofitting corporate copiers
with IDs that showed up on all copied pages:
http://www.garlic.com/~lynn/2005b.html#12

Date: February, 1979

From; M.I.T. SNA study team
      c/o J. H. Saltzer
      IBM Corporation
      Cambridge Scientific Center

Tel:  (617) 253-6016
VNET: JHS at CAMBRIDGE

To:   A. J. Krowe, 620/HAR/3H-29
      B. O. Evans, 6C8/VAL/TD-19

This report is an evaluation of the IBM System Network
Architecture, SNA. The evaluation was performed by a team of
three members of the Computer Systems Research Division of the
M.I.T. Laboratory for Computer Science, acting individually as
consultants to IBM. The study focused on the architecture more
than the implementation, and it considered SNA through release
four.

Perspective (underlined)

The three team members are the following:

Jerome H. Saltzer
Professor of Computer Science and Engineering
M.I.T. Laboratory for Computer Scinece

David D. Clark
Research Associate
M.I.T. Laboratory for Computer Science

David P. Reed
Assistant Professor of Computer Science
M.I.T. Laboratory for Computer Science

The team members are of the academic computer science community,
all with pragmatic interests and experience. Members have
individually designed or in concert with others helped design
time-sharing termainal concentraion networks, the communications
and network software for the Multics system, low and high-level
protocols of the ARPA computer network, and both the hardware and
the protocols of a local computer communication network. Higher
level network protocols, "distributed systems," and the
interactions amoung software systems, data communication systems,
and computer architecture are research specialties of the team
members. The comments in this report are mostly from a practical
rather than a theoretical perspective, but with a strong interest

                                                                1

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

[Lit.] Buffer overruns

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: [Lit.] Buffer overruns
Newsgroups: alt.folklore.computers
Date: Wed, 26 Jan 2005 12:02:13 -0700

pc writes:

i knew a mainframe ops mgr who went to an IBM course for something
new, maybe it was DOS/VS.  he came back shaking his head about one
of the other attendees who was from a Burroughs shop.  seems the
Burroughs man was slowing the class down during the explanations of
new Sysgen options.  he just didn't get it, especially the steps
needed to add additional devices like disk drives.  according to
him, that work shouldn't be needed, his CE just rolled the boxes
through the door and plugged them in.

when i was an undergraduate, one of the changes i made to cp67
(besides adding a whole slew of performance enhancements) was
to add tty/ascii support.

standard os/360 & dos was everything (including specifying all i/o
devices) needed to be defined in sysgen ... although they tried to
alleviate that later in 370 timeframe by introducing "E4" extended
sense channel command code ... which would ask the device what it was
(only new hardware got the "E4", so there still have to be sysgen for
the pre-existing 360 timeframe devices that might still be in use).

cp67 for at least the terminal support had tried to automatically
detect whether it was talking to a 1052 or a 2741 one a line (and what
kind of 2741). the standard telecommunications control unit, 2702 had
"SAD" comments that could dynamically associate a line-scanner with a
specific line ... i.e. the standard cp67 support set the line-scanner
to a specific type and tried some commands (that were known to fail on
the wrong device) and then reset the line-scanner and tried some more
commands.

so I thot I would be devilish clever and do similar scenario when
adding the support for tty/ascii. I got it all tested and it appeared
to work fine ... until the ibm field engineer informed me that I was
just being lucky during my testing. part of the objective was to be
able to have a common dail-up pool with single phone number for all
terminals. my testing had so far been limited to fixed connected lines
... but i hadn't yet tried all three kinds of terminal dialing into
the same phone number. The problem was that they took a short-cut in
the 2702, while they provided the ability to associate any available
line-scanner with any available line ... they had took a short-cut and
hard-wired the oscillators to specific lines ... aka you would have
problems trying to connect a 2741 (134.x baud) on a line with a
oscillator hard-wired for tty (110 baud). The code would correctly
recognize any terminal on any (fixed) line w/o sysgen specification
... but the hardware limitation wouldn't allow dynamic line speed
operation.

So that was one of the things tha prompted the university to build our
own plug-compatible telecommunication controller ... the line-scanner
was implemented in software on the interdata/3 and would strobe the
raise/lower of the incoming signal to dynamically determine the
line-speed. Originally a single interdata/3 handled both the mainframe
channel interface as well as all the line-scanner/port
interfaces. This was later expanded to a cluster of machines with a
Interdata/4 dedicated to handling the mainframe channel interfaces and
multiple interdata/3s handling line-scanner duty.

misc. past 360 plug compatible controller posts:
http://www.garlic.com/~lynn/subtopic.html#360pcm

and to not stray too far from the buffer overrun problem ... this is a
rare example i know of in cp67 that exhibited the problem. because of
tty/ascii spec, i had used one-byte arithmatic in calculating lengths.
The way I remember the event, I think it was called the MIT Urban Lab
... in tech sq ... but a building across the courtyard from 545 (565?
... harvard trust was on street side of the first floor) ... CP67 was
modified to handle some sort of graphics/plotter(?) ascii device at
harvard(?) that had line limit more on the order of 1200 characters.
The max. length fields were correctly modified ... but the use of
one-byte arithmatic wasn't changed ... and so there was 27 cp67 system
failures one day. tale of the tragedy appears here:
http://www.multicians.org/thvv/360-67.html

--
Anne & Lynn Wheeler | http://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, 26 Jan 2005 14:18:52 -0700

CuriousCat writes:

Just of curiousity.

Strings can be represented using either of the following.

1) Sentinel method, use a end-of-string marker
The length of a string is implicit.

2) Value-Len method, bookkeep both value and its len
The length is explicit.

Questions:

If the length of the string is *not known* beforehand, then there is
no difference between the two and the latter representation doesn't
have any additional benefits. Then, the API which C currently has and
the above API would be equivalent. Am I drawing an incorrect
conclusion?

Why do most PLs use the former representation and not the latter?

it was fairly common in the 60s to have len+buffer implementations
where the len was a two byte header ... i have some recollection of a
long ago and far away discussion about the nul-termination being
chosen because it would save a byte (compared to a two byte header)
...  as well as saving a register (and maybe a machine instruction) in
some loop operation implementations ... aka current pointer in a
register plus length (or calculated end, i.e.  start+length) in
another register ... where the nul-termination just required current
pointer and relied on finding the zero byte.

this was in mostly by-gone era with environments of extremely small
memories with extremely few registers ... and lots of extensive manual
optimizations on relatively small amounts of code (typically measured
in k-LOCs or possibly 10k-LOCs; hardly applies these days to anything
... or at least anything that might have any portion of a tcp/ip stack
associated with it).

the 60 era stuff frequently tended to have maximum length and current
length (for dynamic structures that might have various inputs
assigned, which then becomes a 4byte administrative overhead) ...  any
operation that obtained new input would always specify a maximum
acceptable length (for all operations) either explicitly (or
implicitly because it was always part of the buffer structure) and the
input operations would always return either the actual length input
... or the residual length (maximum minus actual) ... and the buffer
header would be updated with the actual.

I believe the majority of PLs actually use the later ... however, it
frequentlys tends to be both a system infrastructure issue coupled
with a language infrastructure issue (i.e. not solely a matter of just
the PL). A PL that in most systems and infrastructures tended to use
the later method ... might be forced to use the former method on a
platform that otherwise heavily relied on the former method
extensively.

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

Noobie SSL certificate problem

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Noobie SSL certificate problem
Newsgroups: sci.crypt
Date: Wed, 26 Jan 2005 14:56:27 -0700

bill.billtaylor writes:

Sorry if this is in the wrong forum.  (if not please point me to the
correct place)

Recently I request an PKI certificate from our client. I received
the certificate but in the mean time delete the request (.arm file).

Is there a way for me to recreate this request from the certificate
that I received (extract the original request)? Or do I need to
start over?

in normal public/private asymmetric environment ... you generate a
public/private key pair. you then distribute the public key via
various mechanisms (while keeping the private key, private and
secure). It is possible for you to digitally sign something with your
private key ... and the receivers can validate that digital signature
(and therefor that the material originated from you) with your
distributed public key. Also, others can asymmetricly encrypt
something with your public key and only you (with your private key)
can decrypt it.

the normal purpose of a PKI certificate is

1) that a trusted third party can attest that the supplied public key
really belongs to you ...  this is applicable to situations where the
relying/recieving parties have no possible direct knowledge of you
... but do have some trust or other relationship with the third party
(generating and distributing the PKI certificates).

2) the trusted 3rd party has no idea who you will be dealing with ...
other than it presumably is somebody that already trusts the 3rd party
...  so the 3rd party returns the information directly to you so that
you can append it to any future correspondance you might have with
unknown relying parties.

this is the letter-of-credit model from the sailing ship days ... as
opposed to existing real-time environments where the relying party
contacts the trusted 3rd party (say a bank or credit bureau) in real
time). The certificate model was created before the days of ubiquitous
electronic communication.

the typical process is for you to generate some form that includes
your public key as part of the contents and then you digitally sign
that form with your private key ... and then send off the form and the
digital signature ... as well as a bunch of other validation
information to the 3rd party PKI certificate issuing entity. The 3rd
party PKI certificate issuing entity uses the public key (included in
the form) to validate the transmitted digital signature. Then they do
something that validates the information that you are who you claim to
be ... and that the public key is really yours. From that they then
can generate a PKI certificate. The PKI certificate will contain your
public key and some sort of identifying information about you.

the original request should have been created with your public key
(which should also be in the body of the returned PKI certificate) and
a digital signature generated by the private key ... so hopefully you
still have a copy of the original private key laying around somewhere.

misc. stuff and past posts about SSL certificates:
http://www.garlic.com/~lynn/subpubkey.html#sslcert

--
Anne & Lynn Wheeler | http://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: Thu, 27 Jan 2005 09:22:23 -0700

CuriousCat writes:

So would it be correct to say that apart from the size/speed issues in
choosing one representation over the other, they suffer from similar
problems from a security point of view? I am thinking (like yourself)
yes, because they appear equivalent from that standpoint.

The only advantage that a value-length representation can offer that I
can think of is the separation offered between the "value" and
"len". So knowing the length before reading in the value helps. This,
unfortunately, is not possible in the sentinel representation since
they are tied strongly together.

there are some additional issues ... one is that the nul-termination
strings requires data to know its length ... and it doesn't give the
length of an empty buffer.

the len+pointer paradigm was used not only for existing string length
but also for max buffer size. a large number of buffer overflows occur
when copying a string into a target area where there is no information
about the length of the target area ... where it become the
responsibility of the programmer to manage the maximum length of the
target buffer. the more things that a programmer has to directly
manager ... the more opportunities for mistakes.

many of the PLs that used pointer+len constructs ... didn't simply use
them for length of areas that contained data ... but also used them
for areas (buffers) that didn't currently contain data and/or might
contain some data ... but the buffer was actually larger than the data
it contained.

the contention is that the larger number of buffer overflows in the c
programming environment is the semantics of copying stuff into buffers
having ambiguous length ... and it was up to the programmer to provide
the administrative function of keeping track of such lengths ... and
was also the source of the mistakes leading to the buffer overflows.

the infrastructures using pointer+len used them not only for current
lengths but also about potential or maximum lengths. the operation and
semantics of copy operations in such environments would honor the
max/potential length values of the target locations ... eliminating
one possible kind of programmer mistake (misspecifying and/or not
specifying at all the length of the target location).

the issue with the semantics of the nul-terminated paradigm ... wasn't
so much that it couldn't be used for deliminating the lengths of data
that existed ... but it wasn't used very well for deliminating the
lengths of things that didn't contain data (maximum length of target
buffers).

a hypothetical (alternative) paradigm (to pointer+len) might involve
defining buffer areas not containing data as being nul-filled ... and
such areas were then terminated by a non-nul ... but that gets into
other potential structural issues.

however, i would contend that the use of pointer+len paradigm handles
both data area lengths and non-data area (i.e. max. length of target
buffers not currently occupied with data) lengths in a much more
consistent and uniform paradigm.

--
Anne & Lynn Wheeler | http://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,comp.security.unix
Date: Thu, 27 Jan 2005 09:31:55 -0700

"D. J. Bernstein" writes:

that don't check for errors. A very-high-level caller uses ferror()
to check for errors after fflush() and before
fsync()+close()+rename(). The code is---thanks to stdio's wise
decision to record errors in an easily accessed error
variable---simpler than C code that passes write errors up the call
chain.

As I said before, this failure-recording strategy compensates
somewhat for the lack of an exception mechanism in C. I'm not saying
it's a perfect substitute---often one still has to pass _read_
errors up the call chain---but it's far better than nothing.

note that the buffer overflow exploits that i quoted from the cve
database ... and the numbers that linux magazine quoted from nist
buffer overflow exploits ... weren't about the percentage or kind of
buffer overflow failures ... they were the percent of exploits where
an attacker could succesfully attack a system using a buffer overflow
vulnerability.

also ... the AMD chip hardware feature previously mentioned (along
with windows XP support) wasn't introduced to prevent buffer overflows
it was introduced to prevent succesful exploits using buffer overflow
vulnerabilities.

one might conclude that if specialized hardware was being introduced
to prevent attackers exploiting buffer overflow vulnerabilities ...
that there is some perception that exploits of buffer overflow
vulnerabilities are fairly significant occurance (and therefor that
buffer overflow vulnerabilities themselves are relatively prevalent).

the hardware isn't even targeted at buffer overflow vulnerability
elimination ... it is buffer overflow vulnerability exploit
elimination.

--
Anne & Lynn Wheeler | http://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, 27 Jan 2005 09:48:18 -0700

jmfbahciv writes:

He was right.  It took gamers to get  this functionality back into
computing.

part of the mainframe problem was once the "sysgen" process was
established ... it was difficult to change its course ... even with
the introduction of device "E4" extended sense (although there was
still a lot of 360 devices that continued to exist for quite some
time).

there were other silly things that tended perpetuate the sysgen
process that also took awhile to change. the os/360 device control
block was addressed with 16bit value ... so initially they all had to
be in the first 64k of real memory ... that may have gotten change so
that they had to be in some contiguous 64k of real memory (doing
base+offset rather than direct address) ... and then systems started
having more devices than could fit in 64k of contiguous memory.

i got to play in the disk engineering lab. when i started, they were
running all the testing stand-alone .... big mainframe configuration
switch that allowed all the engineering disks to be disconnected from
any connectivity except the one being tested. the problem (at the
time) was that running a single engineering disk connected to MVS
operating system, MVS had a MTBF of 15 minutes.

i got to rewrite the i/o subsystem so that multiple concurrent
engineering disks could be tested concurrently in an operating system
environment. random past posts about eliminating all possible
failure modes in a highly hostile i/o environment:
http://www.garlic.com/~lynn/subtopic.html#disk

part of it was that an engineering disk might generate more error
conditions in 15 minute period than a whole disk farm might generate
in years of operation. eliminating failure modes was then not a
hypothetical exercise but having to deal with being constantly being
bombarded in an extremely hostile operational environment.

i got to somewhat play with generalized device recognition and the E4
sense ... but started out needing dummy, predefined device control
block to assign the device to.

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

Relocating application architecture and compiler support

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Relocating application architecture and compiler support
Newsgroups: comp.arch,comp.arch.embedded,alt.folklore.computers
Date: Thu, 27 Jan 2005 09:53:15 -0700

Joe Morris writes:

And this discussion dredges up memories of the one type of OS/360
executable that was relocatable on the fly: the transient (Type 3/4)
SVC.  Typical systems had multiple transient areas, and the
requirements for a type 3/4 SVC (there wasn't really any difference
between the two types) included a prohibition against any
relocatable constants, a requirement of absolute reentrancy, and a
fixed (R12?) base register.

A transient SVC might start execution in one transient area, then
surrender control (for example, to do I/O) and resume execution in a
different area.  The transient SVC handler was responsible for
setting the base register to the appropriate value each time a
transient SVC was dispatched.

what i remember from mft/mvt days was that there were (initially?)
two, 2k transient svc areas. part of the issue was that the loader
wasn't involved in reading code into the transient area ... so there
wasn't any ability to perform swizzling operation on any (relocatable)
address constants.

--
Anne & Lynn Wheeler | http://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: Thu, 27 Jan 2005 11:26:03 -0700

Anne & Lynn Wheeler writes:

however, i would contend that the use of pointer+len paradigm
handles both data area lengths and non-data area (i.e. max. length
of target buffers not currently occupied with data) lengths in a
much more consistent and uniform paradigm.

aka the issue of nul-termination with respect to overrun problems
wasn't so much with respect to the areas containing data where
nul-termination provided the length ... it has been much more
applicable to areas that didn't contain data and/or areas larger than
the data contained.

frequently vulnerabilities, exploits and failures are not where things
are covered .... but where things aren't covered. the nul-termination
convention of providing length information for areas containing (at
least non-nul) data ... but has served less well in providing length
information for areas not contining data ... and/or areas that may be
larger than the data contained.

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

Relocating application architecture and compiler support

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Relocating application architecture and compiler support
Newsgroups: comp.arch,comp.arch.embedded,alt.folklore.computers
Date: Thu, 27 Jan 2005 12:07:32 -0700

Julian Thomas writes:

The /50 emulated only the 1410/7010 and the 7070/74.  No 709x (with
a 4 byte wide memory, performance projections were dismal) and no
1401 (left to the /30 and /40).

There was no microcode assist for memory swapping in these
emulators.  There might have been (I don't know one way or the
other) in a microcode RPQ that was done for a timesharing company
(AB).

this is really vague recollection .. there was something about
partitioning some memory (using base&bound specification) and invoking
emulation using diagnose instruction ... and the gimmick was how to
specify base&bound (with diagnose) while still staying in 360 mode
(aka it wasn't originally intended for swapping or time-sharing ...  I
have vague recollection it had something to do with emulation).

there is a small off-chance that i have a page or two write-up in some
pile of paper someplace. if i get this scanning stuff down ... i'll
try and find it.

on the other hand ... microcode RPQs weren't that uncommon.

--
Anne & Lynn Wheeler | http://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: Thu, 27 Jan 2005 13:15:20 -0700

Walter Bushell writes:

Shouldn't there be hardware protection against this (and the other one)
that is an execute only flag, that would protect code from being written
over or modifying itself? This also allows code to be re-entrant.

Without hardware protection there is buffer except in the mind of the
writer, and perhaps in the mind of the maintainer, unless the language
forces the concept.

the amd hardware and windows support is the inverse. there have been
execute only support around for some time ... but that didn't
necessarily prevent other things from being executed. the inverse is
flagging areas as no-execute (i.e. i-fetch won't occur as opposed to
only i-fetch works).

some of this conceptually may have come from risc and harvard
architects .... some machines have separate, no