Re: [Lit.] Buffer overruns
From: Anne & Lynn Wheeler (lynn_at_garlic.com)
Date: 01/03/05
- Next message: Phil Carmody: "Re: Frobenius, so good?!"
- Previous message: Guy Macon: "Re: A secure hand cipher?"
- In reply to: Anne & Lynn Wheeler: "Re: [Lit.] Buffer overruns"
- Next in thread: Anne & Lynn Wheeler: "Re: [Lit.] Buffer overruns"
- Reply: Anne & Lynn Wheeler: "Re: [Lit.] Buffer overruns"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Sun, 02 Jan 2005 19:17:57 -0700
Anne & Lynn Wheeler <lynn@garlic.com> writes:
> for specific models, you could also get the functional specification
> manual. Some number of the 360 functional characteristics manuals have
> been scanned and made available online:
> http://bitsavers.org/pdf/ibm/360/
oh and this is the 370 principle of operations ... after virtual
storage was announced ... and it includes a little more detailed
description of the storage key-based protection mechanism ...
as well as stuff added to the storage keys for virtual memory
operation (pg. 38) ... and is nominally defined to be upward
compatible with 360.
http://bitsavers.org/pdf/ibm/370/GA22-7000-4_370PoO_Sep75.pdf
The psw status storage protection is privilege status ... it can have
a value between 0&15 (zero meaning matches everything). If the value
in the psw is non-zero and doesn't match the 4bit value in the
"storage key" (one for each 2k block of real memory) then there is a
storage protection exception.
for 370 there are 7 bits (of logical 8bit byte) defined (see
pge. 38 in the above referenced document):
bit(s)
0-3 protection key value
4 fetch protection flag
5 storage reference bit
6 storage change bit
7 unused
bits 5&6 are status bits added for 370 so that the hardware can
record if the associated 2k block of memory has ever been referenced
and/or changed. normal programming operation is to test the bits
and reset then reset the storage key value with zeros for bit 5
(and possibly bit 6).
standard 360 only had (privilege mode) insert storage key (ISK) and
set storage key (SSK) operations (which is how the page replacement
algorithm on 360/67 interegated the reference bit). for 370, a new
instructiuon, reset reference bit (RRB) ... the instruction condition
code indicated the reference bit value before it was cleared to zero.
standard 360 (& 370) store protect was implied by a non-zero key in
the psw and a mismatch between the PSW key and the storage key for a
2k block of storage. there was no separate bit that specified store
protection. Setting the fetch protect flag resulted in both fetches
and stores being checked for a mismatch between the 4bit PSW key and
the 4kbit storage protection key (for 2k range of storage). the
description on pg. 38 in the above referenced principle of operations
specifically says that with fetch protection flag is set ... fetch
protection is applied to all storage fetches ... both instruction and
instruction operands (w/o regard to the type of fetch).
there is no provision (at least in the standard 360/370 architecture
implementation) for execute-only fetch operation (i.e. allow
instruction fetches but disallow instruction operand fetches) because
there is only a single bit used .... the fetch protection bit
* when the fetch protect bit is zero there is only store protect
checks when there is a non-zero PSW key and a mismatch between the PSW
key and the storage key for the 2k block of storage.
* when the fetch protect bit is one there is both store protect checks
and fetch protect checks when there is a non-zero PSW key and a
mismatch between the PSW key and the storag ekey for the 2k block of
storage (and as specified, fetch protection is applied equally to
instruction fetches as well as instruction operation fetches).
In most of the 360s & 370s .. the storage key array could have an 8bit
byte for each 2k block of real memory. In the vanilla 360 case, that
might result in their being 3 unused bits for every storage key
(although in 360 time-frame, it might just be as likely to have
implemented only the five bits per 2k real memory ... and if the
feature wasn't installed the storage key array wouldn't exist at all
on the machine ... and ISK/SSK instructions would just be null
operations).
The 360/67 used the 7bit storage key array defined in 370 ... aka a
4bit protection key value, a fetch protection flag, a storage
reference bit and a storage change bit.
I have no knowledge of any possible "under the covers" support in the
storage protection feature implementation on the 360/40 that could
have used an extra bit in the storage key array to be able to specify
execute-only (aka allow instruction storage fetch ... but preclude
instruction operand storage fetch). I never tripped across any
definition of any 360 or 370 documents that happen to mention it.
Given the description of separate fetch and store protection
"features" on 360 ... it is possible that if the fetch protection
wasn't installed ... there would only be 4bit key for each 2k storage
block in the storage key array ... and the only support check for
storage protection violation on stores (with no hardware or microcode
added to check for storage protection violations on fetches).
note that in the 360 principle of operations manual (referenced in the
previous posting) description that starts on pg.17 and carries over to
pg.18 ... specifically describes setting store protect (i.e. fetch
protect bit is zero) or setting "fetch-and-store" protect (i.e.
setting the fetch protect bit to one). There is no additional flag bit
defined (at least in the 360 principle of operations) ... supporting
an 3rd state/condition ... allow instruction fetch but disallow
instruction operand fetch.
for some topic drift ... a couple recent posts on cache replacement
algorithms:
http://www.garlic.com/~lynn/2004q.html#18 PR/SM Dynamic Time Slice calculation
http://www.garlic.com/~lynn/2004q.html#58 CAS and LL/SC (was Re: High Level Assembler for MVS & VM & VSE)
http://www.garlic.com/~lynn/2004q.html#72 IUCV in VM/CMS
http://www.garlic.com/~lynn/2004q.html#73 Athlon cache question
http://www.garlic.com/~lynn/2004q.html#76 Athlon cache question
http://www.garlic.com/~lynn/2004q.html#77 Athlon cache question
-- Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
- Next message: Phil Carmody: "Re: Frobenius, so good?!"
- Previous message: Guy Macon: "Re: A secure hand cipher?"
- In reply to: Anne & Lynn Wheeler: "Re: [Lit.] Buffer overruns"
- Next in thread: Anne & Lynn Wheeler: "Re: [Lit.] Buffer overruns"
- Reply: Anne & Lynn Wheeler: "Re: [Lit.] Buffer overruns"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
