Why (conceptually) does executive mode code need unrestricted kernel mode access ?

[Simon Clubley]

Why, at a conceptual level, does executive mode code need unrestricted
kernel mode access ?

If kernel mode access is required, then why can't executive mode code go
through a normal system service to provide the additional functionality
like everyone else does ?

For example, what does RMS actually _need_ direct unrestricted kernel mode
access for and why can't this be provided for by a normal system service ?

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.

No specific reason for the questions, it's just something that occurred
to me while reading some documentation.

Thanks,

Simon.

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

[VAXman-]

In article <qn7d5t$tcf$1...@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>Why, at a conceptual level, does executive mode code need unrestricted
>kernel mode access ?
>
>If kernel mode access is required, then why can't executive mode code go
>through a normal system service to provide the additional functionality
>like everyone else does ?
>
>For example, what does RMS actually _need_ direct unrestricted kernel mode
>access for and why can't this be provided for by a normal system service ?

It is. $CMKRNL.

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

It does.



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

I speak to machines with the voice of humanity.

[Simon Clubley]

On 2019-10-04, VAXman- @SendSpamHere.ORG <VAX...@SendSpamHere.ORG> wrote:
> In article <qn7d5t$tcf$1...@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>>Why, at a conceptual level, does executive mode code need unrestricted
>>kernel mode access ?
>>
>>If kernel mode access is required, then why can't executive mode code go
>>through a normal system service to provide the additional functionality
>>like everyone else does ?
>>
>>For example, what does RMS actually _need_ direct unrestricted kernel mode
>>access for and why can't this be provided for by a normal system service ?
>
> It is. $CMKRNL.
>

No, sys$cmkrnl() is the system service that provides the direct
unrestricted kernel mode access from executive mode that I mention
above. This effectively turns VMS into, at best, a 3-mode operating system.

My question is why does executive mode code need direct unrestricted
access to kernel mode and why can't executive mode code have the same
more controlled access to kernel mode (via the normal system services)
that the rest of us use in our normal user mode programs ?

For example, when we call the lock manager or sys$qio() code from normal
user mode code, we end up running kernel mode code, but it is done via
a controlled system service interface that only allows specific operations
to be carried out in kernel mode.

Why does executive mode code require a direct and unrestricted access
to kernel mode ? What is so special about RMS that it requires direct
kernel mode access and why can't this kernel mode access be via some
kind of system service interface instead ?

Once again, there's no specific reason for the questions; it's just
something that occurred to me.

[erga...@gmail.com]

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?

[Simon Clubley]

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.

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.

[VAXman-]

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

[Simon Clubley]

On 2019-10-04, VAXman- @SendSpamHere.ORG <VAX...@SendSpamHere.ORG> wrote:

> In article <qn853b$eeh$1...@dont-email.me>, Simon Clubley <clubley@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,