[Info-vax] Why (conceptually) does executive mode code need unrestricted kernel mode access ?

[VAXman- at SendSpamHere.ORG]

In article <qn853b$eeh$1 at dont-email.me>, Simon Clubley <clubley at remove_me.eisner.decus.org-Earth.UFP> writes:
>On 2019-10-04, ergamenes at gmail.com <ergamenes at gmail.com> wrote:
>> On Friday, 4 October 2019 13:16:00 UTC+1, Simon Clubley  wrote:
>>
>>> If it's a privileges problem, the system service could check that the
>>> previous mode was executive mode before deciding whether to allow the
>>> specific operation in question.
>>
>> Slightly confused by this part, that's what CMKRNL does. Surely the 
>> question is why do you not need CMKRNL privileges to use SYS$CMKRNL
>> from EXEC mode?
>
>No, I was thinking that maybe RMS was given full access to kernel
>mode because it needed to carry out (for example) privileged operations
>on behalf of a non-privileged user.

It needs kernel mode access to read or modify some VMS data structures
that have KR or KW mode access.  There aren't that many $CMKRNL calls 
within RMS as you may think.  

It's NOT *uncontrolled* access!  Access is controlled by the maintainers
of VMS and, therefore, RMS.  The reason that the executive mode "escape
system" exists in $CMKRNL is because there is simply no way to get into
kernel mode from an outer mode if a calling process does not posses the
CMKRNL privilege.  One can change modes from an inner mode to outer mode
via an REI but there is no way to any inner mode without the change mode
exception fielded by the change mode handler for that mode.  One can NOT
get into SUPERVISOR, EXECUTIVE, or KERNEL from USER; EXECUTIVE or KERNEL
from SUPERVISOR; or KERNEL from EXECUTIVE.  The pathway to inner mode is
via a change mode exception and that then sends control to a change mode
handler defined in the SCB.



>However, there are far better ways to handle that than just give
>executive mode code uncontrolled kernel access and then let the
>executive mode code do whatever it wants in kernel mode.
>
>This question came about because I started thinking why, conceptually,
>the VMS design _requires_ executive mode code to have uncontrolled
>access to kernel mode, and so far, I am not coming up with any good
>answers. The things I am coming up with, such as privilege handling,
>seem to have a more reasonable way of handling the problem at hand.

I'd rather RMS do its minimal tasks possessing kernel mode access via a 
$CMKRNL call invoking specific routines needed rather than to create yet
another system service which a privileged user might invoke improperly.

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.