[Info-vax] CRTL and RMS vs SSIO

[Simon Clubley]

On 2021-10-13, Lawrence D?Oliveiro <lawrencedo99 at gmail.com> wrote:
> On Thursday, October 14, 2021 at 7:14:08 AM UTC+13, Simon Clubley wrote:
>>
>> On 2021-10-12, Lawrence D?Oliveiro <lawren... at gmail.com> wrote:
>>
>>> On Wednesday, October 13, 2021 at 9:54:14 AM UTC+13, Stephen Hoffman wrote: 
>>>
>>>> The DEC OpenVMS advanced development group did do a prototype of 
>>>> OpenVMS on Mach a ~quarter-century ago. 
>>> 
>>> Yeah, but Mach is a microkernel, with all the downsides that microkernels have. 
>> 
>> 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 ?

For the record, I think the IME (and similar devices) are not a good
thing to have in hardware unless you can _guarantee_ they can be disabled
in all cases.

> So the idea that microkernels have real-world security advantages is pretty dubious at best.
>

Ever heard of seL4 ?

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.

>> BTW, QNX, which is a RTOS with a massive user base, is microkernel based.
>
> I think it?s getting pushed aside by Linux in some areas. Remember NASA?s Mars copter? Yup, that was the first time running Linux and a bunch of other open-source software on another planet.
>
>>>> Possible areas where kernel modifications might necessary? Linux memory 
>>>> management is thoroughly two-ring, and OpenVMS expectations are 
>>>> four-ring. Do you drop those areas from OpenVMS, and force app source 
>>>> code changes? 
>>> 
>>> Where is there app code that cares about this? 
>>> 
>> 
>> Any program that interacts with DCL for one simple example.
>
> 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.

>> In the current VMS design, you can't move DCL into user mode, or allow 
>> user-controlled code to execute in DCL's supervisor mode, without ending 
>> up with an operating system that has all the security of MS-DOS.
>
> Yes, but 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.

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.

Simon.

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