On Fri, 27 Jan 2006 14:37:11 -0600 "Craddock, Chris" <[EMAIL PROTECTED]> wrote:
:>> :>There are mechanisms for doing that which do not violate integrity. :>> Define what you mean by "integrity". :>Integrity in this case means making sure you are looking at the address :>space you think you are looking at. Your definition (below) is only a :>part of the overall requirement. How can it be other than what I expect? :>> I see integrity as preventing a problem state routine from doing :>something :>> malicious or outside it's box :>Yes. :>> and preventing a supervisor state routine from accidentally doing :>> something unexpected. :>This is getting close to the real point. You are asking help to write a :>supervisor state function to do something that is completely outside of :>the architecture. The instruction you wanted to use will do what you :>want, but without the protection of being wrapped in the operating :>system's service environment, there is a grave risk you will find :>yourself out in the weeds sooner or later. Make that a certainty. "The sky is falling. The sky is falling." :>> I agree that there is a need to provide a means so that a supervisor :>state :>> routine does not unknowingly PT somewhere where integrity might be :>> violated, but I do see the need for the supervisor state routine to :>say :>> even though this PT appears to violate integrity - it does not - so :>let :>> me do it anyway. :>The instruction architecture (i.e. PoPs) allows a supervisor program to :>do a great many things whether they are "safe" or not. The operating :>system provides a software architecture in which those things can be :>done safely and reliably. :>The software architecture does not allow you to branch into some :>arbitrary address space, even though the hardware does allow it. There :>are good reasons for that and you haven't given any justification at all :>for ignoring them. The good reasons being ........????? :>> :>PT/PTI is the WRONG way to get primary addressability to another :>space. :>> That is an opinion. :>> I hope you can accept that reasonable people can disagree. :>You may call it an opinion if you want, but you will find 100% of the :>IBM core technology design people agree with that opinion. (Right guys?) :>Reasonable people may very well disagree, but it would be unwise to :>disagree without understanding the reasons why the architecture is the :>way it is. The reason being....?? :>> :>You have only two legal choices. Your can set up space-switch PC :>> :>services in the target address space and use a PC to get there, or :>you :>> :>can schedule an SRB. :>> Yes, I am aware of the legal choices. :>> The first one involves screwing around with the client address space :>so :>> that it might have bad effects, and the second is out of line. :>Here's where we get into really deep water. I described the two approved :>ways of getting addressability to another address space. The first one :>(PC services) is really only available to service providers. It would be :>irrational to go planting PC routines in random address spaces. :>If you are intent on "snooping" in any other address space than your :>own, then the one and only legal choice you have is to schedule an SRB :>into that space and snoop to your heart's content. There is NOTHING out :>of line about that. In fact, that is how most of the monitor products :>operate. It certainly is "out of line". There is no way to pass control to the SRB and have the SRB pass control back. Synchronization IS required. :>> I tend to write supervisor state code carefully. It would take real :>bad :>> planning to end up with "a supervisor state PSW pointing to the :>ozone". :>It isn't a matter of how careful you are. There is nothing you or anyone :>else could do in a rational amount of code that would prevent these :>problems from occurring. Stop for just a moment and ask yourself why the :>cross memory services architecture is designed the way it is. I promise :>you it isn't just to frustrate would-be snoopers. OK. Explain to me the reason why z/OS does not support a task level AX. -- Binyamin Dissen <[EMAIL PROTECTED]> http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. ---------------------------------------------------------------------- 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
