[Info-vax] CRTL and RMS vs SSIO

[Simon Clubley]

On 2021-10-14, Lawrence D?Oliveiro <lawrencedo99 at gmail.com> wrote:
> On Friday, October 15, 2021 at 7:32:33 AM UTC+13, Simon Clubley wrote:
>> On 2021-10-13, Lawrence D?Oliveiro <lawren... at gmail.com> wrote: 
>>> On Thursday, October 14, 2021 at 7:14:08 AM UTC+13, Simon Clubley wrote: 
>>>> 
>>>> Microkernels have moved on and microkernels have massive security advantages. 
>>>
>>> Counterexample: Intel?s infamous Management Engine that exerts total control
>>> over its CPUs, that the OS cannot bypass, runs microkernel-based MINIX, and
>>> turned out to have massive security holes in it. 
>>> 
>> Wasn't that due to the applications running on top of Minix instead of 
>> Minix itself ?
>> 
>> The massive advantage of microkernels is that code which would otherwise 
>> be in a shared fully privileged kernel address space is in fact isolated 
>> in its own address space with far fewer access rights to other parts of 
>> the system.
>
> But these separate processes are still able to compromise system security, as happened with the Intel MINIX example? So where exactly is the ?massive advantage? in security?
>

In that things which would operate in a privileged shared address space
environment in a normal monolithic kernel (such as drivers) would be
isolated in a microkernel. That's where the benefits come from.

>>> The fact that DCL runs in supervisor mode is an internal implementation matter.
>>> It could be replaced by a thread or an entirely separate process (even a privileged
>>> one), for example, and what difference would that make to user-mode code?
>>>
>> Unlike the Unix shells you are clearly thinking of, DCL provides services 
>> to a program directly while the program is running.
>
> The same thing can be done from a separate thread or process.
>

Not with how DCL is currently implemented.

>>> ... as far as I know there is no user-controlled code in DCL.
>>
>> _Normally_, there isn't. :-) 
>> 
>> The point of my comments is that DCL needs to operate in a more 
>> privileged environment than is available to user-mode code. 
>
> I don?t understand why, unless it is to get around limitations of the current VMS design. Once you free yourself from that, you no longer need to structure your solutions the same way.
>
> Replace ?DCL? with ?process that is longer-lived than most user programs? and you will see what I mean. In the *nix world, we just call that a ?shell?.
>
>> In the current design, you can't fold user-mode code into DCL's 
>> supervisor mode or move DCL into user mode without having a total 
>> breakdown in system security, hence you need an extra mode other 
>> than the normal KU modes to run DCL in.
>
> Scrap that current design, then.

If you had been reading comp.os.vms for the last few years Lawrence,
you would know that I have made multiple suggestions in exactly this
area. I suspect I've annoyed multiple VSI employees with my rather
firm negative opinions on this part of VMS.

Simon.

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