This is how the rest of the world views DEC and VMS:

https://arstechnica.com/gadgets/2023/10/long-gone-dec-is-still-powering-the-world-of-computing/

Den 2023-10-07 kl. 16:23, skrev John Vottero:
> This is how the rest of the world views DEC and VMS:
>
> https://arstechnica.com/gadgets/2023/10/long-gone-dec-is-still-powering-the-world-of-computing/

There is also a thread on the VSI Forum on that matter.
https://forum.vmssoftware.com/viewtopic.php?f=5&t=8866

John Vottero <johnvottero@gmail.com> writes:

> This is how the rest of the world views DEC and VMS:

> https://arstechnica.com/gadgets/2023/10/long-gone-dec-is-still-powering-the-world-of-computing/

I saw this elsewhere (Bluesky or Mastodon or the bird).

Very nearly everything they have to say about the history is wrong.

--
Rich Alderson news@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen

On Saturday, October 7, 2023 at 5:49:49 PM UTC-7, Rich Alderson wrote:
> John Vottero <johnv...@gmail.com> writes:
>
> > This is how the rest of the world views DEC and VMS:
>
> > https://arstechnica.com/gadgets/2023/10/long-gone-dec-is-still-powering-the-world-of-computing/
> I saw this elsewhere (Bluesky or Mastodon or the bird).
>
> Very nearly everything they have to say about the history is wrong.
It is well known that VMS people moved to working on NT.

How many ideas transferred is less obvious.

Many ideas on how to build modern processors were well known,
so it isn't so obvious that you can connect the origin of one to another.

There is a book that traces all of modern electronics to WW2 radar.

The radar receivers needed silicon point contact rectifiers.
Someone not so much later, had a silicon rod that rectified one
way on one end, and the other way on the other end.

That is, one end was p-type and the other end n-type.
Understanding that led, somewhat indirectly, to the bipolar
transistor and much of today's electronics.

They also trace much of computer technology to some computers
that were part of the early warning radar, to detect incoming Soviet
missiles.

No-one can be sure what would have happened differently
without WW2 radar, but it does make a good story.

In article <371cf2e8-9ca1-4571-964e-e70642a75943n@googlegroups.com>,
gah4@u.washington.edu (gah4) wrote:

> It is well known that VMS people moved to working on NT.
>
> How many ideas transferred is less obvious.

The actual relationship is with DEC's MICA. That was intended (in the
final version of the plan) to have a common kernel that could support VMS
and Ultrix environments. <https://en.wikipedia.org/wiki/DEC_MICA>

Windows NT originally had three "environmental subsystems", Win32, OS/2
(dropped at Windows XP) and POSIX (replaced by Interix, then Windows
Services for Linux).

The Windows NT kernel is quite VMS-like in its concepts, but the
implementation is very different, being written in C and using only user
and supervisor privilege levels. The API that it provides is not
published, except for the functions that device drivers use.
<https://en.wikipedia.org/wiki/Architecture_of_Windows_NT>

John

In article <memo.20231008084235.10140D@jgd.cix.co.uk>, jgd@cix.co.uk
(John Dallman) wrote:

> The actual relationship is with DEC's MICA. That was intended (in
> the final version of the plan) to have a common kernel that could
> support VMS and Ultrix environments. . . .

This idea was widespread in the 1990s. IBM's Workplace OS was planned to
unify MS-DOS, Windows, OS/2 and generic UNIX environments at first, and
add OS/400, AIX, Taligent and classic MacOS later.

<https://en.wikipedia.org/wiki/Workplace_OS>

Workplace OS was a comprehensive failure; the partial success with
Windows NT was achieved via huge development costs and more modest
objectives.

John

On 2023-10-08 02:49, Rich Alderson wrote:
> John Vottero <johnvottero@gmail.com> writes:
>
>> This is how the rest of the world views DEC and VMS:
>
>> https://arstechnica.com/gadgets/2023/10/long-gone-dec-is-still-powering-the-world-of-computing/
>
> I saw this elsewhere (Bluesky or Mastodon or the bird).
>
> Very nearly everything they have to say about the history is wrong.

Yeah. While I like the fact that they tried, on a technical level there
was very little that was correct.

Johnny

On 2023-10-08 09:42, John Dallman wrote:
> In article <371cf2e8-9ca1-4571-964e-e70642a75943n@googlegroups.com>,
> gah4@u.washington.edu (gah4) wrote:
>
>> It is well known that VMS people moved to working on NT.
>>
>> How many ideas transferred is less obvious.
>
> The actual relationship is with DEC's MICA. That was intended (in the
> final version of the plan) to have a common kernel that could support VMS
> and Ultrix environments. <https://en.wikipedia.org/wiki/DEC_MICA>
>
> Windows NT originally had three "environmental subsystems", Win32, OS/2
> (dropped at Windows XP) and POSIX (replaced by Interix, then Windows
> Services for Linux).

Yes. And I think there is a foreword in some Windows-NT book by Dave
Cutler where he says as much himself. Spiritually descended from RSX via
VMS, but more directly from MICA.

> The Windows NT kernel is quite VMS-like in its concepts, but the
> implementation is very different, being written in C and using only user
> and supervisor privilege levels. The API that it provides is not
> published, except for the functions that device drivers use.
> <https://en.wikipedia.org/wiki/Architecture_of_Windows_NT>

I wish people would stop getting so hung up on the different "privilege"
levels. That is such a minor detail in anything that it hardly matters.
I don't understand how it has become such a huge thing in VMS circuits.

Johnny

On 10/8/2023 9:54 AM, Johnny Billquist wrote:
> On 2023-10-08 09:42, John Dallman wrote:
>> The Windows NT kernel is quite VMS-like in its concepts, but the
>> implementation is very different, being written in C and using only user
>> and supervisor privilege levels. The API that it provides is not
>> published, except for the functions that device drivers use.
>> <https://en.wikipedia.org/wiki/Architecture_of_Windows_NT>
>
> I wish people would stop getting so hung up on the different "privilege"
> levels. That is such a minor detail in anything that it hardly matters.
> I don't understand how it has become such a huge thing in VMS circuits.

In many ways E is an implementation detail. I don't think
RMS running in K would mean a big difference for anything
else.

But I think the existence of S has implications beyond
internal implementation. It is what makes the VMS shell
model and process <> image possible. Without it it
seems likely that VMS would have had something fork like.

Arne

On Sun, 2023-10-08 at 12:50 -0400, Arne Vajhøj wrote:
> Without it it seems likely that VMS would have had something fork
> like.

Unix-like forks can fork off.

--
Tactical Nuclear Kittens

On 2023-10-08 18:50, Arne Vajhøj wrote:
> On 10/8/2023 9:54 AM, Johnny Billquist wrote:
>> On 2023-10-08 09:42, John Dallman wrote:
>>> The Windows NT kernel is quite VMS-like in its concepts, but the
>>> implementation is very different, being written in C and using only user
>>> and supervisor privilege levels. The API that it provides is not
>>> published, except for the functions that device drivers use.
>>> <https://en.wikipedia.org/wiki/Architecture_of_Windows_NT>
>>
>> I wish people would stop getting so hung up on the different
>> "privilege" levels. That is such a minor detail in anything that it
>> hardly matters. I don't understand how it has become such a huge thing
>> in VMS circuits.
>
> In many ways E is an implementation detail. I don't think
> RMS running in K would mean a big difference for anything
> else.
>
> But I think the existence of S has implications beyond
> internal implementation. It is what makes the VMS shell
> model and process <> image possible. Without it it
> seems likely that VMS would have had something fork like.

No. As demonstrated by VMS on x86-64. No need. You can do that/solve
that with just two modes. The only real boundary is between user mode
and everything else.

Johnny

On 2023-10-09, Johnny Billquist <bqt@softjar.se> wrote:
> On 2023-10-08 18:50, Arne Vajhøj wrote:
>> On 10/8/2023 9:54 AM, Johnny Billquist wrote:
>>> On 2023-10-08 09:42, John Dallman wrote:
>>>> The Windows NT kernel is quite VMS-like in its concepts, but the
>>>> implementation is very different, being written in C and using only user
>>>> and supervisor privilege levels. The API that it provides is not
>>>> published, except for the functions that device drivers use.
>>>> <https://en.wikipedia.org/wiki/Architecture_of_Windows_NT>
>>>
>>> I wish people would stop getting so hung up on the different
>>> "privilege" levels. That is such a minor detail in anything that it
>>> hardly matters. I don't understand how it has become such a huge thing
>>> in VMS circuits.

Because, if done properly (unlike the way VMS did it), it could have
had real isolation, and hence security, benefits.

A comparable example would be how the isolation built into microkernel
designs has real security benefits.

>>
>> In many ways E is an implementation detail. I don't think
>> RMS running in K would mean a big difference for anything
>> else.
>>
>> But I think the existence of S has implications beyond
>> internal implementation. It is what makes the VMS shell
>> model and process <> image possible. Without it it
>> seems likely that VMS would have had something fork like.

That is not a good thing. The Unix approach is better, especially in
today's security environment.

>
> No. As demonstrated by VMS on x86-64. No need. You can do that/solve
> that with just two modes. The only real boundary is between user mode
> and everything else.
>

As far as most of x86-64 VMS is concerned, it still does have 4 modes.

It's just that 2 of them are emulated in the very lowest levels of
x86-64 VMS.

Simon.

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

On 2023-10-08, John Dallman <jgd@cix.co.uk> wrote:
> In article <371cf2e8-9ca1-4571-964e-e70642a75943n@googlegroups.com>,
> gah4@u.washington.edu (gah4) wrote:
>
>> It is well known that VMS people moved to working on NT.
>>
>> How many ideas transferred is less obvious.
>
> The actual relationship is with DEC's MICA. That was intended (in the
> final version of the plan) to have a common kernel that could support VMS
> and Ultrix environments. <https://en.wikipedia.org/wiki/DEC_MICA>
>

There's also the small matter of what the "P" in AXP is alleged to stand
for. :-)

> Windows NT originally had three "environmental subsystems", Win32, OS/2
> (dropped at Windows XP) and POSIX (replaced by Interix, then Windows
> Services for Linux).
>
> The Windows NT kernel is quite VMS-like in its concepts, but the
> implementation is very different, being written in C and using only user
> and supervisor privilege levels. The API that it provides is not
> published, except for the functions that device drivers use.
><https://en.wikipedia.org/wiki/Architecture_of_Windows_NT>
>

However, I thought WNT took its internal OO model from MICA (or at
least was inspired by it).

Simon.

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

Johnny Billquist <bqt@softjar.se> wrote:
>I wish people would stop getting so hung up on the different "privilege"
>levels. That is such a minor detail in anything that it hardly matters.
>I don't understand how it has become such a huge thing in VMS circuits.

It has become a huge thing because these days it is a unique thing. A lot
of operating systems used to have multiple levels, but not many (any?) are
left. So when people whose experience is limited to Windows and Unix look
at VMS architecturally this is the first thing they see as being very strange.

So many of the specific practices discussed in the Red Book no longer even
exist in operating systems classes today.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

On 10/9/2023 5:40 AM, Johnny Billquist wrote:
> On 2023-10-08 18:50, Arne Vajhøj wrote:
>> On 10/8/2023 9:54 AM, Johnny Billquist wrote:
>>> On 2023-10-08 09:42, John Dallman wrote:
>>>> The Windows NT kernel is quite VMS-like in its concepts, but the
>>>> implementation is very different, being written in C and using only
>>>> user
>>>> and supervisor privilege levels. The API that it provides is not
>>>> published, except for the functions that device drivers use.
>>>> <https://en.wikipedia.org/wiki/Architecture_of_Windows_NT>
>>>
>>> I wish people would stop getting so hung up on the different
>>> "privilege" levels. That is such a minor detail in anything that it
>>> hardly matters. I don't understand how it has become such a huge
>>> thing in VMS circuits.
>>
>> In many ways E is an implementation detail. I don't think
>> RMS running in K would mean a big difference for anything
>> else.
>>
>> But I think the existence of S has implications beyond
>> internal implementation. It is what makes the VMS shell
>> model and process <> image possible. Without it it
>> seems likely that VMS would have had something fork like.
>
> No. As demonstrated by VMS on x86-64. No need. You can do that/solve
> that with just two modes. The only real boundary is between user mode
> and everything else.

VMS x86-64 has still 4 modes and it still enables
DCL in P1 space.

The x86-64 only proved that the 4 modes in the OS do
not require 4 modes in HW.

Arne

On 10/9/2023 9:05 AM, Simon Clubley wrote:
> On 2023-10-09, Johnny Billquist <bqt@softjar.se> wrote:
>> On 2023-10-08 18:50, Arne Vajhøj wrote:
>>> On 10/8/2023 9:54 AM, Johnny Billquist wrote:
>>>> On 2023-10-08 09:42, John Dallman wrote:
>>>>> The Windows NT kernel is quite VMS-like in its concepts, but the
>>>>> implementation is very different, being written in C and using only user
>>>>> and supervisor privilege levels. The API that it provides is not
>>>>> published, except for the functions that device drivers use.
>>>>> <https://en.wikipedia.org/wiki/Architecture_of_Windows_NT>
>>>>
>>>> I wish people would stop getting so hung up on the different
>>>> "privilege" levels. That is such a minor detail in anything that it
>>>> hardly matters. I don't understand how it has become such a huge thing
>>>> in VMS circuits.
>
> Because, if done properly (unlike the way VMS did it), it could have
> had real isolation, and hence security, benefits.
>
> A comparable example would be how the isolation built into microkernel
> designs has real security benefits.
>
>>>
>>> In many ways E is an implementation detail. I don't think
>>> RMS running in K would mean a big difference for anything
>>> else.
>>>
>>> But I think the existence of S has implications beyond
>>> internal implementation. It is what makes the VMS shell
>>> model and process <> image possible. Without it it
>>> seems likely that VMS would have had something fork like.
>
> That is not a good thing. The Unix approach is better, especially in
> today's security environment.

Remember that VMS was designed just before MIT decided to
enable password on the accounts on the systems in their
computer lab (per the old Stallman story).

It was a different time.

If MIT considered it appropriate to not have passwords
on all their accounts on the systems in their
computer lab, then DEC deciding not to block access
from S to more privileged modes seems not a big thing.

45 years later the world is very different.

Arne

On 09/10/2023 21:20, Arne Vajhøj wrote:
> On 10/9/2023 9:05 AM, Simon Clubley wrote:
>> On 2023-10-09, Johnny Billquist <bqt@softjar.se> wrote:
>>> On 2023-10-08 18:50, Arne Vajhøj wrote:
>>>> On 10/8/2023 9:54 AM, Johnny Billquist wrote:
>>>>> On 2023-10-08 09:42, John Dallman wrote:
>>>>>> The Windows NT kernel is quite VMS-like in its concepts, but the
>>>>>> implementation is very different, being written in C and using
>>>>>> only user
>>>>>> and supervisor privilege levels. The API that it provides is not
>>>>>> published, except for the functions that device drivers use.
>>>>>> <https://en.wikipedia.org/wiki/Architecture_of_Windows_NT>
>>>>>
>>>>> I wish people would stop getting so hung up on the different
>>>>> "privilege" levels. That is such a minor detail in anything that it
>>>>> hardly matters. I don't understand how it has become such a huge thing
>>>>> in VMS circuits.
>>
>> Because, if done properly (unlike the way VMS did it), it could have
>> had real isolation, and hence security, benefits.
>>
>> A comparable example would be how the isolation built into microkernel
>> designs has real security benefits.
>>
>>>>
>>>> In many ways E is an implementation detail. I don't think
>>>> RMS running in K would mean a big difference for anything
>>>> else.
>>>>
>>>> But I think the existence of S has implications beyond
>>>> internal implementation. It is what makes the VMS shell
>>>> model and process <> image possible. Without it it
>>>> seems likely that VMS would have had something fork like.
>>
>> That is not a good thing. The Unix approach is better, especially in
>> today's security environment.
>
> Remember that VMS was designed just before MIT decided to
> enable password on the accounts on the systems in their
> computer lab (per the old Stallman story).
>
> It was a different time.
>
> If MIT considered it appropriate to not have passwords
> on all their accounts on the systems in their
> computer lab, then DEC deciding not to block access
> from S to more privileged modes seems not a big thing.
>
> 45 years later the world is very different.
>
> Arne
>
>

When I started with PDP 11/44 there were no passwords at all - just
hello 100,1 for the application, or...
All the user terminals were auto-login

--
Chris

On Monday, October 9, 2023 at 1:20:28 PM UTC-7, Arne Vajhøj wrote:

(snip)

> Remember that VMS was designed just before MIT decided to
> enable password on the accounts on the systems in their
> computer lab (per the old Stallman story).
> It was a different time.
> If MIT considered it appropriate to not have passwords
> on all their accounts on the systems in their
> computer lab, then DEC deciding not to block access
> from S to more privileged modes seems not a big thing.
> 45 years later the world is very different.

Systems I remember from about 45 years ago had passwords
for users, but all files were world readable.

Everyone was, more or less, on the same side, working for
the same overall organization.

On 2023-10-09 15:05, Simon Clubley wrote:
> On 2023-10-09, Johnny Billquist <bqt@softjar.se> wrote:
>> On 2023-10-08 18:50, Arne Vajhøj wrote:
>>> On 10/8/2023 9:54 AM, Johnny Billquist wrote:
>>>> On 2023-10-08 09:42, John Dallman wrote:
>>>>> The Windows NT kernel is quite VMS-like in its concepts, but the
>>>>> implementation is very different, being written in C and using only user
>>>>> and supervisor privilege levels. The API that it provides is not
>>>>> published, except for the functions that device drivers use.
>>>>> <https://en.wikipedia.org/wiki/Architecture_of_Windows_NT>
>>>>
>>>> I wish people would stop getting so hung up on the different
>>>> "privilege" levels. That is such a minor detail in anything that it
>>>> hardly matters. I don't understand how it has become such a huge thing
>>>> in VMS circuits.
>
> Because, if done properly (unlike the way VMS did it), it could have
> had real isolation, and hence security, benefits.

I don't really agree. It's not as if you magically can do some new fancy
security stuff with more levels that is not possible otherwise. Thinking
this way is mostly self-delusions. Another belief in some silver bullet
that could just solve all the problems.

> A comparable example would be how the isolation built into microkernel
> designs has real security benefits.

I don't see any comparison. And microkernels can also be done with just
two modes of the processor.

>>> In many ways E is an implementation detail. I don't think
>>> RMS running in K would mean a big difference for anything
>>> else.
>>>
>>> But I think the existence of S has implications beyond
>>> internal implementation. It is what makes the VMS shell
>>> model and process <> image possible. Without it it
>>> seems likely that VMS would have had something fork like.
>
> That is not a good thing. The Unix approach is better, especially in
> today's security environment.

What kind of Unix security are you thinking about here?
Fork? Or just that shells are normal programs?
DCL being a privileged piece of code means that there are security
implications, yes. Shells not requiring any special privileges makes it
easier to keep safe.

Historically, Unix was much worse than VMS ever was. Anything that
wanted to know anything about the system had to go and read through
/dev/kmem, which meant that any and all data was possible to read. The
security leaks of that can't even be described in words. And the only
privilege was root, which meant you could do everything. And anything
that wanted to do anything out of the ordinary then had to run as root.
Don't even start on counting the number of exploits based on that
detail... Including various forks done in processes that ran as root,
where people managed to figure out one way or another to fool the
process to fork and exec something unintentional, leading to privilege
escalations. Starting with just your path variable...

>> No. As demonstrated by VMS on x86-64. No need. You can do that/solve
>> that with just two modes. The only real boundary is between user mode
>> and everything else.
>>
>
> As far as most of x86-64 VMS is concerned, it still does have 4 modes.
>
> It's just that 2 of them are emulated in the very lowest levels of
> x86-64 VMS.

Yes. But that shows how little those 4 modes actually matter. VAX could
have had just two modes, and played with the mapping from day 1, and
never even mentioned the terms "executive" and "supervisor". It was just
a convenient help in the hardware on the VAX to make this a bit simpler.

Johnny

On 2023-10-10, Johnny Billquist <bqt@softjar.se> wrote:
> On 2023-10-09 15:05, Simon Clubley wrote:
>> On 2023-10-09, Johnny Billquist <bqt@softjar.se> wrote:
>>> On 2023-10-08 18:50, Arne Vajhøj wrote:
>>>> On 10/8/2023 9:54 AM, Johnny Billquist wrote:
>>>>> On 2023-10-08 09:42, John Dallman wrote:
>>>>>> The Windows NT kernel is quite VMS-like in its concepts, but the
>>>>>> implementation is very different, being written in C and using only user
>>>>>> and supervisor privilege levels. The API that it provides is not
>>>>>> published, except for the functions that device drivers use.
>>>>>> <https://en.wikipedia.org/wiki/Architecture_of_Windows_NT>
>>>>>
>>>>> I wish people would stop getting so hung up on the different
>>>>> "privilege" levels. That is such a minor detail in anything that it
>>>>> hardly matters. I don't understand how it has become such a huge thing
>>>>> in VMS circuits.
>>
>> Because, if done properly (unlike the way VMS did it), it could have
>> had real isolation, and hence security, benefits.
>
> I don't really agree. It's not as if you magically can do some new fancy
> security stuff with more levels that is not possible otherwise. Thinking
> this way is mostly self-delusions. Another belief in some silver bullet
> that could just solve all the problems.
>
>> A comparable example would be how the isolation built into microkernel
>> designs has real security benefits.
>
> I don't see any comparison. And microkernels can also be done with just
> two modes of the processor.
>

The comparison is that, instead of stuffing all of the kernel code into one
fully privileged address space (ie: kernel mode), in a microkernel the
kernel code is broken up into multiple, lesser privileged, address spaces
all of which are isolated from each other.

Likewise, if the various modes had been used properly, you could have had
a version of VMS with chunks of it properly isolated from each other.

>> That is not a good thing. The Unix approach is better, especially in
>> today's security environment.
>
> What kind of Unix security are you thinking about here?
> Fork? Or just that shells are normal programs?
> DCL being a privileged piece of code means that there are security
> implications, yes. Shells not requiring any special privileges makes it
> easier to keep safe.
>

Yes. Everything should be as unprivileged as possible so if it gets
compromised, it could help reduce the damage which can be done.

> Historically, Unix was much worse than VMS ever was. Anything that
> wanted to know anything about the system had to go and read through
> /dev/kmem, which meant that any and all data was possible to read. The
> security leaks of that can't even be described in words. And the only
> privilege was root, which meant you could do everything. And anything
> that wanted to do anything out of the ordinary then had to run as root.
> Don't even start on counting the number of exploits based on that
> detail... Including various forks done in processes that ran as root,
> where people managed to figure out one way or another to fool the
> process to fork and exec something unintentional, leading to privilege
> escalations. Starting with just your path variable...
>

We don't compare the security on version 1.0 of VMS with the security
of modern VMS versions. Likewise, stuff done in the Unix of the 1970s
is not applicable in 2023 unless modern-way Unix still has the same issues.

Simon.

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

On 10/9/2023 4:20 PM, Arne Vajhøj wrote:
> On 10/9/2023 9:05 AM, Simon Clubley wrote:
>> On 2023-10-09, Johnny Billquist <bqt@softjar.se> wrote:
>>> On 2023-10-08 18:50, Arne Vajhøj wrote:
>>>> On 10/8/2023 9:54 AM, Johnny Billquist wrote:
>>>>> On 2023-10-08 09:42, John Dallman wrote:
>>>>>> The Windows NT kernel is quite VMS-like in its concepts, but the
>>>>>> implementation is very different, being written in C and using
>>>>>> only user
>>>>>> and supervisor privilege levels. The API that it provides is not
>>>>>> published, except for the functions that device drivers use.
>>>>>> <https://en.wikipedia.org/wiki/Architecture_of_Windows_NT>
>>>>>
>>>>> I wish people would stop getting so hung up on the different
>>>>> "privilege" levels. That is such a minor detail in anything that it
>>>>> hardly matters. I don't understand how it has become such a huge thing
>>>>> in VMS circuits.
>>
>> Because, if done properly (unlike the way VMS did it), it could have
>> had real isolation, and hence security, benefits.
>>
>> A comparable example would be how the isolation built into microkernel
>> designs has real security benefits.
>>
>>>>
>>>> In many ways E is an implementation detail. I don't think
>>>> RMS running in K would mean a big difference for anything
>>>> else.
>>>>
>>>> But I think the existence of S has implications beyond
>>>> internal implementation. It is what makes the VMS shell
>>>> model and process <> image possible. Without it it
>>>> seems likely that VMS would have had something fork like.
>>
>> That is not a good thing. The Unix approach is better, especially in
>> today's security environment.
>
> Remember that VMS was designed just before MIT decided to
> enable password on the accounts on the systems in their
> computer lab (per the old Stallman story).
>
> It was a different time.
>
> If MIT considered it appropriate to not have passwords
> on all their accounts on the systems in their
> computer lab, then DEC deciding not to block access
> from S to more privileged modes seems not a big thing.
>

Actually, until the 414s most places didn't require passwords including
ARPANET. Most people's userid was their name (mine was "bill" until
2115. Still is on most of my home machines. But I have always had
a password. Just call me paranoid.) Learning userids was trivial,
Just use finger!! And then you had rlogin making it easy to jump around
from machine to machine once you compromised any of them.

I remember when the announcement that passwords would be required on
ARPANET. Many places went ballistic. How could you impose such a
hardship on users.

Times have definitely changed and not for the better.

> 45 years later the world is very different.
>
> Arne
>
>

bill

On 2023-10-10 19:41, Simon Clubley wrote:
> On 2023-10-10, Johnny Billquist <bqt@softjar.se> wrote:
>> On 2023-10-09 15:05, Simon Clubley wrote:
>>> On 2023-10-09, Johnny Billquist <bqt@softjar.se> wrote:
>>>> On 2023-10-08 18:50, Arne Vajhøj wrote:
>>>>> On 10/8/2023 9:54 AM, Johnny Billquist wrote:
>>>>>> On 2023-10-08 09:42, John Dallman wrote:
>>>>>>> The Windows NT kernel is quite VMS-like in its concepts, but the
>>>>>>> implementation is very different, being written in C and using only user
>>>>>>> and supervisor privilege levels. The API that it provides is not
>>>>>>> published, except for the functions that device drivers use.
>>>>>>> <https://en.wikipedia.org/wiki/Architecture_of_Windows_NT>
>>>>>>
>>>>>> I wish people would stop getting so hung up on the different
>>>>>> "privilege" levels. That is such a minor detail in anything that it
>>>>>> hardly matters. I don't understand how it has become such a huge thing
>>>>>> in VMS circuits.
>>>
>>> Because, if done properly (unlike the way VMS did it), it could have
>>> had real isolation, and hence security, benefits.
>>
>> I don't really agree. It's not as if you magically can do some new fancy
>> security stuff with more levels that is not possible otherwise. Thinking
>> this way is mostly self-delusions. Another belief in some silver bullet
>> that could just solve all the problems.
>>
>>> A comparable example would be how the isolation built into microkernel
>>> designs has real security benefits.
>>
>> I don't see any comparison. And microkernels can also be done with just
>> two modes of the processor.
>>
>
> The comparison is that, instead of stuffing all of the kernel code into one
> fully privileged address space (ie: kernel mode), in a microkernel the
> kernel code is broken up into multiple, lesser privileged, address spaces
> all of which are isolated from each other.
>
> Likewise, if the various modes had been used properly, you could have had
> a version of VMS with chunks of it properly isolated from each other.

I don't think the processor modes is really usable for that isloation of
thing in the first place, so I think it's a false comparison.
Don't try to get things used for something they are not meant for, or
fit for...

>>> That is not a good thing. The Unix approach is better, especially in
>>> today's security environment.
>>
>> What kind of Unix security are you thinking about here?
>> Fork? Or just that shells are normal programs?
>> DCL being a privileged piece of code means that there are security
>> implications, yes. Shells not requiring any special privileges makes it
>> easier to keep safe.
>>
>
> Yes. Everything should be as unprivileged as possible so if it gets
> compromised, it could help reduce the damage which can be done.

I certainly agree with that.

>> Historically, Unix was much worse than VMS ever was. Anything that
>> wanted to know anything about the system had to go and read through
>> /dev/kmem, which meant that any and all data was possible to read. The
>> security leaks of that can't even be described in words. And the only
>> privilege was root, which meant you could do everything. And anything
>> that wanted to do anything out of the ordinary then had to run as root.
>> Don't even start on counting the number of exploits based on that
>> detail... Including various forks done in processes that ran as root,
>> where people managed to figure out one way or another to fool the
>> process to fork and exec something unintentional, leading to privilege
>> escalations. Starting with just your path variable...
>>
>
> We don't compare the security on version 1.0 of VMS with the security
> of modern VMS versions. Likewise, stuff done in the Unix of the 1970s
> is not applicable in 2023 unless modern-way Unix still has the same issues.

The root privileges, and related fallout is still relevant in Unix
today, even if things are better than they used to be.

Johnny

In article <ug42d3$18sge$1@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>We don't compare the security on version 1.0 of VMS with the security
>of modern VMS versions. Likewise, stuff done in the Unix of the 1970s
>is not applicable in 2023 unless modern-way Unix still has the same issues.

Unix is still a security dumpster fire. The concept of UID 0
being uniquely (and totally) privileged still very much exists,
and `fork` allows one to leak state to unprivileged code
trivially. Then there's setuid....

The idea that you can get access to kernel memory via a special
device file is (IMHO) less relevant, but combined with the other
things it's particularly dangerous.

Unix was not designed with security as a primary goal, and many
of the consequences of its early design still stand.

And none of this even begins to discuss implementation issues,
such as memory-unsafe code in critical security paths, or
susceptibility to speculation-related side-channel attacks,
as opposed to purely architectural issues.

Ironically, much of this was fixed in plan9 (at least in the
architectural model), and some of the relevant changes have been
retrofitted into e.g. Linux, but the older issues persist. They
_can_ be sandboxed much more effectively these days, though, and
by any reasonable metric, modern Linux is pretty secure. It
could be _better_, but as you point out, it's nothing like 1970s
and 80s Unix.

- Dan C.

In article <ug4hod$2h6$1@news.misty.com>,
Johnny Billquist <bqt@softjar.se> wrote:
>On 2023-10-10 19:41, Simon Clubley wrote:
>> Likewise, if the various modes had been used properly, you could have had
>> a version of VMS with chunks of it properly isolated from each other.
>
>I don't think the processor modes is really usable for that isloation of
>thing in the first place, so I think it's a false comparison.
>Don't try to get things used for something they are not meant for, or
>fit for...

I got the impression that's roughly what Simon was saying. The
architectural privilege levels on the VAX weren't as useful as
initially thought.

>[snip]
>>> Historically, Unix was much worse than VMS ever was. Anything that
>>> wanted to know anything about the system had to go and read through
>>> /dev/kmem, which meant that any and all data was possible to read. The
>>> security leaks of that can't even be described in words. And the only
>>> privilege was root, which meant you could do everything. And anything
>>> that wanted to do anything out of the ordinary then had to run as root.
>>> Don't even start on counting the number of exploits based on that
>>> detail... Including various forks done in processes that ran as root,
>>> where people managed to figure out one way or another to fool the
>>> process to fork and exec something unintentional, leading to privilege
>>> escalations. Starting with just your path variable...
>>>
>>
>> We don't compare the security on version 1.0 of VMS with the security
>> of modern VMS versions. Likewise, stuff done in the Unix of the 1970s
>> is not applicable in 2023 unless modern-way Unix still has the same issues.
>
>The root privileges, and related fallout is still relevant in Unix
>today, even if things are better than they used to be.

Indeed. But modern Unix's also have capability systems that can
obviate much of the need for root. It's possible to run complex
network services on low ports without resorting to being `root`,
for instance.

- Dan C.

On 2023-10-12 17:49, Dan Cross wrote:
> In article <ug4hod$2h6$1@news.misty.com>,
> Johnny Billquist <bqt@softjar.se> wrote:
>> On 2023-10-10 19:41, Simon Clubley wrote:
>>> Likewise, if the various modes had been used properly, you could have had
>>> a version of VMS with chunks of it properly isolated from each other.
>>
>> I don't think the processor modes is really usable for that isloation of
>> thing in the first place, so I think it's a false comparison.
>> Don't try to get things used for something they are not meant for, or
>> fit for...
>
> I got the impression that's roughly what Simon was saying. The
> architectural privilege levels on the VAX weren't as useful as
> initially thought.

I got the impression that he was complaining that VMS did not make use
of the modes in a "good enough" way from a security point of view.

My point is that this is not what the different processor modes are
meaningful for. They are a nice way to add some extra safety, and
structure things in a sortof ordered way. But you should not try to make
them your security mechanism.
Anything beyond user is equivalent from a security point of view. Trying
to make the other modes imply different security layers is not really
useful, for multiple reasons.

>> The root privileges, and related fallout is still relevant in Unix
>> today, even if things are better than they used to be.
>
> Indeed. But modern Unix's also have capability systems that can
> obviate much of the need for root. It's possible to run complex
> network services on low ports without resorting to being `root`,
> for instance.

Yes. Capabilities are an effort to avoid having everything run as root.
But root still exists, and shortcircuit all the security systems.
And getting rid of is in itself equially scary. Who knows how stuck your
system might become if root were to go away. Everything is so basically
dependent on root existing and being special, still.

Johnny