> I don't
> remember for sure, but it was probably possible for a caller to have a read
> command executed with a storage address that would cause data being read to
> overlay
> storage that was outside his region, partition, or whatever the big chunk of
> storage was called. So you could clobber the operating system as well as
> other users' central storage with read commands.
I don't think so. I remember writing code for OS/360 that, during
early testing, incorrectly calculated a buffer size requirement.
Sure enough, when a subsequent READ CCW tried to read into
beyond the end of the GETMAINed area, a S0C4 was the result
because the following storage was in Key0.
(This may have been either MFT or MVT -- can't remember. I
seem to remember that MVT was more robust in terms of storage
keys for OS related control blocks, etc.)
> Date: Wed, 11 Jun 2008 11:51:26 -0400
> From: [EMAIL PROTECTED]
> Subject: Re: EXCP access methos
> To: IBM-MAIN@BAMA.UA.EDU
>
>
>
> In a message dated 6/11/2008 8:25:57 A.M. Central Daylight Time,
> [EMAIL PROTECTED] writes:
> >It's my understanding that for many decades EXCP has not executed
> channel programs in place and as provided by the caller.
>
> Back in the days before paging systems, back when there was no virtual or
> real storage, back when storage was just called "storage", EXCP would execute
> the channel program in place and as provided by the caller, but with extra
> CCWs
> in front of the caller's first CCW. These extra CCWs were added to insure
> data set integrity; i.e., the caller's channel program cannot go to any track
> that is not in the list of allocated extents created by OPEN. I don't
> remember for sure, but it was probably possible for a caller to have a read
> command executed with a storage address that would cause data being read to
> overlay
> storage that was outside his region, partition, or whatever the big chunk of
> storage was called. So you could clobber the operating system as well as
> other users' central storage with read commands. The various DASD access
> methods on these systems (OS/360, DOS/360, TOS/360, and BPS/360) were QSAM,
> BSAM,
> BPAM, BDAM, ISAM, and QISAM. They all used EXCP internally to do I/O
> requests, except for possibly ISAM which sometimes had a naked SIO
> instruction (or
> so I was told). I don't know very much about the other access methods for
> devices other than DASD and tape (e.g., TCAM, QTAM, and BTAM), but I would
> guess
> that they all also used EXCP internally.
>
> With the advent of virtual and real storage, IBM chose to require that the
> data addresses inside CCWs be interpreted by the I/O hardware as real
> addresses. Thus a scheme was needed to convert from virtual addresses to real
> addresses in order to make the transition to the new systems transparent to
> customers. The MVS architects decided to create a new I/O concept called "IOS
> Driver" which is a new layer of software that performs I/O requests without
> having
> to use EXCP. They also invented a new "access method" called STARTIO which
> replaced EXCP as the lowest possible level access method. The ancient DASD
> access methods, QSAM etc., still use EXCP, but EXCP was redesigned to
> interface between the callers of EXCP (ancient access methods), which present
> EXCP
> with channel programs containing virtual addresses, and the new lower level
> and
> thus intermediate, internal "access method" called STARTIO, which assumes
> that the channel program is in non-pageable storage, with real addresses of
> data, and which was built by a trusted software component. Many new functions
> in MVS were designed to use STARTIO directly themselves, such as the paging
> supervisor, while some new MVS components were designed to use EXCP, probably
> in order to get the new code written most quickly. JES2, e.g., originally
> used EXCP (I haven't dealt with JES2 internals now for 20+ years, so it may
> be
> different now), probably because JES2 was developed from HASP, which used
> EXCP, and that code was already well debugged, so why rewrite it?
>
> >Rather,
> they are moved to protected storage so the user can not modify
> them on the fly
>
> Yes, unless you have EXCP appendages, but these must be loaded from an
> authorized library, so the customer can control their use.
>
> >they are prefixed to prevent seeks to prohibited
> tracks; virtual addresses are translated to real; etc. I'd
> further expect changes to CCW architecture to accommodate XA and
> later 64-bit addressing and new I/O architecture.
>
> Correct on all counts.
>
> >So the "checks
> to prevent it" may be a matter of IBM's resource allotment: rather
> than continually update EXCP code to all new hardware features,
> it's easier simply to prohibit use of EXCP for such purposes.
>
> I concur. Also IBM would like to "encourage" users to migrate all
> applications to the latest and greatest software and hardware solutions;
> namely, VSAM,
> DFSMS, ESS controllers, etc., so typically IBM adds support to "strategic"
> products and components first and then maybe, reluctantly and much later, to
> non-strategic components. They, too, have limited resources for developing
> new products and adding support for new products into other, older, products
> that must interface with the new products.
>
> >It has always struck me as bizarre that the OS supports running
> channel programs built by problem-state programs. This is secure
> only if the channel programs are in effect interpreted rather than
> executed directly. A more rational layering of functions should
> have channel programs built only by trustworthy supervisor-state
> code.
>
> I don't know to what you are referring here by "the OS". Problem-state
> programs in z/OS build channel programs which are then converted to safe,
> trusted
> equivalent channel programs by trusted software components before being
> started by IOS.
>
> In VM, CCWs are not interpreted as far as I know, but rather the channel
> program is scanned before being executed in order to determine how to let it
> run
> safely on its own. The only way I can think of to execute a channel program
> interpretively is to do a separate I/O request for each CCW in the channel
> program (of course, with the necessary CCWs in front of it for it to work
> correctly). Then if a CCW reads data, the data would be read somewhere that
> VM
> could trust, and then move that data into the caller's buffer. This is
> similar to how interpretive machine instruction is handled. But the overhead
> in
> interpreting channel programs would be prohibitive, I believe, so they are
> not
> really interpreted. They are first made safe with the proper CCWs in front
> of those supplied by the problem-state caller and then allowed to run on
> their
> own.
>
> Bill Fairchild
> Rocket Software
>
>
_________________________________________________________________
Search that pays you back! Introducing Live Search cashback.
http://search.live.com/cashback/?&pkw=form=MIJAAF/publ=HMTGL/crea=srchpaysyouback
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
