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

[Simon Clubley]

On 2019-10-04, VAXman-  @SendSpamHere.ORG <VAXman- at SendSpamHere.ORG> wrote:
> In article <qn853b$eeh$1 at dont-email.me>, Simon Clubley <clubley at remove_me.eisner.decus.org-Earth.UFP> writes:
>>
>>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.  
>

Thank you Brian. That's the bit I was missing.

> 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.
>

A non-privileged user certainly cannot get into supervisor mode or above
from user mode unless they find a vulnerability. However, don't forget
that because of how privileged images are handled on VMS, it's possible
for code running in supervisor mode to get into executive or kernel mode,
even without the user holding CMEXEC or CMKRNL. The privilege is only
required on the privileged image that the supervisor mode code has access to.

>
>
>>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.
>

You can protect against that by requiring the system service be called
from executive mode. That means RMS gets to do what it needs in kernel
mode, but nothing else.

I admit I am looking at it in light of knowledge of how operating systems
are designed these days instead of 40 years ago, but the idea of going
into kernel mode to directly access those data structures, instead of
via some system service, just doesn't feel like the correct design
approach. Executive mode could have been this highly privileged, but
isolated from kernel mode, layer within VMS.

And yes, I know that if VMS was being designed today, then it would be
implemented internally very differently. :-)

Thanks for the answers, Brian. I was curious to know _why_ executive
mode needed the level of access to kernel mode that it has.

Thanks,

Simon.

-- 
Simon Clubley, clubley at remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.