RE: MATCTX (was Detecting changing objects...) -- MI400

Now that you've raised your hand Bruce perhaps you could explain IBM's
reasoning in this. I can understand why you might want to prevent me
resolving a system pointer to a system domain object from the user state
but I can't see the exposure in de-referencing a system pointer I
already have. Frankly I don't see the "greater security, integrity,
auditing etc", I just see added nuisance value.  

TrailBlazer Systems, Inc.
http://www.softwarejungle.com
AS/400 E-Commerce Solutions

Chaos, panic, & disorder - my work here is done.

> -----Original Message-----
> From: bvining@VNET.IBM.COM [SMTP:bvining@VNET.IBM.COM]
> Sent: Wednesday, November 24, 1999 1:24 PM
> To:   MI400@midrange.com
> Subject:      MATCTX (was Detecting changing objects...)
> 
> Lief,
> 
> It is my understanding that back in the V2R3 time frame a decision was
> made to disallow the usage of system pointers to system domain objects
> when in user state and security level 40 or above is in effect.  This
> decision was implemented in the machine by checking the object domain
> (or hardware storage protection associated the addressed storage) when
> dereferencing the pointer (that is, touching the object).  Due to this
> a whole lot of "unblocked" MI became effectively blocked at levels 40
> and 50; though please note that the instruction itself did not
> necessarily change -- it was implementation of dereferencing the
> pointer that did.  What drove this decision (domain checking) was the
> desire for greater security, integrity, auditing, etc.
> 
> It is due to this blocking at higher levels of security that IBM
> developed the wrapper API (QusMaterializeContext); it is not the case
> that IBM disallowed the instruction because the API existed.
> 
> So the total function of matctx is not available at all security
> levels due to the implementation of domain checking (it was nothing
> personal about the instruction :-)) and to re-instate that function
> would be to create special case exceptions in how pointer checking is
> conducted in the machine on an instruction by instruction basis; which
> is a path that no one I know of really wanted to go down.  As an
> alternative IBM instead came up with the API which provided the matctx
> data in a format that would not require alot of rework by developers.
> 
> I hope this helps clear things up,
> Bruce
> 
> >
> > [Leif Svalgaard]  Then explain *why* MATCTX at levels 40 and 50
> >gives
> > a protection violation while the wrapped API does not. Not *how
> >come*.
> > That I understand fully (the API being a system state program), but
> >*why*
> > with the API available it was deemed necessary to disallow MATCTX
> > directly?
> >
> > [Leif Svalgaard]  I'll try from this angle: Since an API is
> >available
> > why is the function not directly available? What is the rationale
> >for
> > disallowing the direct function in user state programs and at the
> > same time supplying an API with the same function that allows
> > the developer to do it anyway?
> >
> > [Leif Svalgaard]  One more time:
> > Why is this function not available directly?
> >
> 
> 
> +---
> | This is the MI Programmers Mailing List!
> | To submit a new message, send your mail to MI400@midrange.com.
> | To subscribe to this list send email to MI400-SUB@midrange.com.
> | To unsubscribe from this list send email to
> MI400-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator:
> dr2@cssas400.com
> +---
+---
| This is the MI Programmers Mailing List!
| To submit a new message, send your mail to MI400@midrange.com.
| To subscribe to this list send email to MI400-SUB@midrange.com.
| To unsubscribe from this list send email to MI400-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: dr2@cssas400.com
+---