Just saw a mention of a proposal from Intel to produce a simplified
variant of the AMD64/x86-64 architecture, leaving out a whole bunch of
legacy stuff that doesn’t get much use these days.

One of the things proposed for removal is the Ring 1 and Ring 2 privilege modes.

Does OpenVMS on AMD64 make use of these modes?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 10/17/2024 7:04 PM, Lawrence D'Oliveiro wrote:

Just saw a mention of a proposal from Intel to produce a simplified
variant of the AMD64/x86-64 architecture, leaving out a whole bunch of
legacy stuff that doesn’t get much use these days.

One of the things proposed for removal is the Ring 1 and Ring 2 privilege modes.

Does OpenVMS on AMD64 make use of these modes?

My understanding of the proposed changes are:

64 bit OS 64 bit app - works
64 bit OS 32 bit apps - works
32 bit OS 32 bit apps - gone
32 bit OS 16 bit apps - gone
16 bit OS 16 bit apps - gone

VMS x86-64 is 64 bit OS 64 bit apps (the fact that pointers are
often stored with only low 32 bit bit in RAM is irrelevant).

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 2024-10-17 at 19:27 -0400, Arne Vajhøj wrote:

One of the things proposed for removal is the Ring 1 and Ring 2
privilege
modes.

Does OpenVMS on AMD64 make use of these modes?

My understanding of the proposed changes are:

64 bit OS 64 bit app - works
64 bit OS 32 bit apps - works
32 bit OS 32 bit apps - gone
32 bit OS 16 bit apps - gone
16 bit OS 16 bit apps - gone

VMS x86-64 is 64 bit OS 64 bit apps (the fact that pointers are
often stored with only low 32 bit bit in RAM is irrelevant).

His question was about the ring priviledge modes, not what apps and
what OS will run on the proposed architecture. If you don't know, say
so!
--
Tactical Nuclear Kittens

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 10/18/2024 1:53 AM, Single Stage to Orbit wrote:

On Thu, 2024-10-17 at 19:27 -0400, Arne Vajhøj wrote:

One of the things proposed for removal is the Ring 1 and Ring 2
privilege
modes.

Does OpenVMS on AMD64 make use of these modes?

My understanding of the proposed changes are:

64 bit OS 64 bit app - works
64 bit OS 32 bit apps - works
32 bit OS 32 bit apps - gone
32 bit OS 16 bit apps - gone
16 bit OS 16 bit apps - gone

VMS x86-64 is 64 bit OS 64 bit apps (the fact that pointers are
often stored with only low 32 bit bit in RAM is irrelevant).

His question was about the ring priviledge modes, not what apps and
what OS will run on the proposed architecture.

I read the question. And I tried to answer.

No changes for 64 bit OS 64 bit apps - and that includes VMS.

(excluding boot process, which need to do some stuff before
it actually becomes a running 64 bit OS)

The details about why has been mentioned a few times
previously.

x86-64 in long mode only support 2 modes in PTE's, so
VMS x86-64 is a hardware 2 mode OS 4 mode OS - U in ring 3,
S, E and K in ring 0.

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 2024-10-18 at 06:50 -0400, Arne Vajhøj wrote:

His question was about the ring priviledge modes, not what apps and
what OS will run on the proposed architecture.

I read the question. And I tried to answer.

No changes for 64 bit OS 64 bit apps - and that includes VMS.

(excluding boot process, which need to do some stuff before
it actually becomes a running 64 bit OS)

The details about why has been mentioned a few times
previously.

x86-64 in long mode only support 2 modes in PTE's, so
VMS x86-64 is a hardware 2 mode OS 4 mode OS - U in ring 3,
S, E and K in ring 0.

So in reality, user space and kernel space. That's a bit crap, tbh,
there are times where drivers, kernel code and user space could use a
bit of hardware separation.
--
Tactical Nuclear Kittens

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Arne Vajhøj wrote:

x86-64 in long mode only support 2 modes in PTE's, so
VMS x86-64 is a hardware 2 mode OS 4 mode OS - U in ring 3,
S, E and K in ring 0.

Not exactly.

Ring 3 is used for Exec, Super, and User

Ring 0 is used for kernel and for transitions between modes (SWIS)

Running Exec and Super in ring 0 would blow away the separation (which,
I might add, is there more for stability than for security, before I unintentionally re-start that debate)

Camiel

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11/3/2024 9:06 AM, Camiel Vanderhoeven wrote:

Arne Vajhøj wrote:

x86-64 in long mode only support 2 modes in PTE's, so
VMS x86-64 is a hardware 2 mode OS 4 mode OS - U in ring 3,
S, E and K in ring 0.

Not exactly.

Ring 3 is used for Exec, Super, and User

Ring 0 is used for kernel and for transitions between modes (SWIS)

Running Exec and Super in ring 0 would blow away the separation (which,
I might add, is there more for stability than for security, before I unintentionally re-start that debate)

You are more afraid that DCL or RMS would step on VMS than
applications would step on DCL or RMS?

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Arne Vajhøj wrote:

On 11/3/2024 9:06 AM, Camiel Vanderhoeven wrote:

Arne Vajhøj wrote:

x86-64 in long mode only support 2 modes in PTE's, so
VMS x86-64 is a hardware 2 mode OS 4 mode OS - U in ring 3,
S, E and K in ring 0.

Not exactly.

Ring 3 is used for Exec, Super, and User

Ring 0 is used for kernel and for transitions between modes (SWIS)

Running Exec and Super in ring 0 would blow away the separation
(which, I might add, is there more for stability than for security,
before I unintentionally re-start that debate)

You are more afraid that DCL or RMS would step on VMS than
applications would step on DCL or RMS?

No, certainly not. That is why we have a separate set of page tables for
each mode. For instance, a page that has kernel write / exec read
protections is represented by the following PTEs in these 4 sets of page tables:

kernel mode: S(upervisor) W(riteable)
exec mode: U(ser) R(eadable)
super mode: not present
user mode: not present

Camiel

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11/3/2024 11:38 AM, Camiel Vanderhoeven wrote:

Arne Vajhøj wrote:

On 11/3/2024 9:06 AM, Camiel Vanderhoeven wrote:

Arne Vajhøj wrote:

x86-64 in long mode only support 2 modes in PTE's, so
VMS x86-64 is a hardware 2 mode OS 4 mode OS - U in ring 3,
S, E and K in ring 0.

Not exactly.

Ring 3 is used for Exec, Super, and User

Ring 0 is used for kernel and for transitions between modes (SWIS)

Running Exec and Super in ring 0 would blow away the separation
(which, I might add, is there more for stability than for security,
before I unintentionally re-start that debate)

You are more afraid that DCL or RMS would step on VMS than
applications would step on DCL or RMS?

No, certainly not. That is why we have a separate set of page tables for
each mode. For instance, a page that has kernel write / exec read
protections is represented by the following PTEs in these 4 sets of page tables:

kernel mode: S(upervisor) W(riteable)
exec mode: U(ser) R(eadable)
super mode: not present
user mode: not present

So if U code tries to access some data structures requiring
S or E to access, then at the low level it does not
fail for lack of access but it fails for not existing for that mode
(at the higher level it may be translated to a more traditional access violation)?

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <672813c5$0$719$14726298@news.sunsite.dk>,
Arne Vajhøj <arne@vajhoej.dk> wrote:

On 11/3/2024 11:38 AM, Camiel Vanderhoeven wrote:

Arne Vajhøj wrote:

On 11/3/2024 9:06 AM, Camiel Vanderhoeven wrote:

Arne Vajhøj wrote:

x86-64 in long mode only support 2 modes in PTE's, so
VMS x86-64 is a hardware 2 mode OS 4 mode OS - U in ring 3,
S, E and K in ring 0.

Not exactly.

Ring 3 is used for Exec, Super, and User

Ring 0 is used for kernel and for transitions between modes (SWIS)

Running Exec and Super in ring 0 would blow away the separation
(which, I might add, is there more for stability than for security,
before I unintentionally re-start that debate)

You are more afraid that DCL or RMS would step on VMS than
applications would step on DCL or RMS?

No, certainly not. That is why we have a separate set of page tables for
each mode. For instance, a page that has kernel write / exec read
protections is represented by the following PTEs in these 4 sets of page
tables:

kernel mode: S(upervisor) W(riteable)
exec mode: U(ser) R(eadable)
super mode: not present
user mode: not present

The more I think about the more fascinating it sounds.

So if I write a C program with:

char __align(13) buf[8192];

and the C code call SYS$SETPRT with PRT$C_UREW on that, then
it works like.

logical/application level:

1 page of 8 KB with:
logK : write
logE : write
logS : read
logU : read

physical/hardware level:

2 pages of 4 KB each in four different page tables:

logK => page table with: physK : write, physU : ? (should not matter)
logE => page table with: physK : write, physU : write
logS => page table with: physK : write, physU : read
logU => page table with: physK : write, physU : read

It's pretty obvious that VMS has to use multiple page tables to
emulate systems with multiple protection modes on systems that
don't have such things in hardware. There's no other reasonable
artictecture.

On x86 in long mode, specifically, page table entries have bits
for readability (the "P", for "Present", bit implies that the
page is readable, unless memory protection keys are used, in
which case a page can be marked write- or execute-only),
writability (if set, the page is writeable; otherwise not); and non-executability (if NX is set, the page is not executable,
otherwise it is).

Separately, there is a bit for whether the page is accessible
from userspace or not (the U/S bit): if set, the page can be
accessed from ring 3, in accordance with the other permission
bits, otherwise not. By default, page-level write permission
bits are ignored for supervisor mode stores (that is, stores
from any ring other than ring 3) unless the the `WP` bit in
control register CR0 is set; if CR0.WP is set and the page is
not marked writable, then the kernel can't write to it, unless
it the same page is also mapped with suitable permissions at
some other address.

A number of bits in CR4 and a handful of MSRs will also affect
behavior around page permission enforcement.

- Dan C.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11/3/2024 11:38 AM, Camiel Vanderhoeven wrote:

Arne Vajhøj wrote:

On 11/3/2024 9:06 AM, Camiel Vanderhoeven wrote:

Arne Vajhøj wrote:

x86-64 in long mode only support 2 modes in PTE's, so
VMS x86-64 is a hardware 2 mode OS 4 mode OS - U in ring 3,
S, E and K in ring 0.

Not exactly.

Ring 3 is used for Exec, Super, and User

Ring 0 is used for kernel and for transitions between modes (SWIS)

Running Exec and Super in ring 0 would blow away the separation
(which, I might add, is there more for stability than for security,
before I unintentionally re-start that debate)

You are more afraid that DCL or RMS would step on VMS than
applications would step on DCL or RMS?

No, certainly not. That is why we have a separate set of page tables for
each mode. For instance, a page that has kernel write / exec read
protections is represented by the following PTEs in these 4 sets of page tables:

kernel mode: S(upervisor) W(riteable)
exec mode: U(ser) R(eadable)
super mode: not present
user mode: not present

The more I think about the more fascinating it sounds.

So if I write a C program with:

char __align(13) buf[8192];

and the C code call SYS$SETPRT with PRT$C_UREW on that, then
it works like.

logical/application level:

1 page of 8 KB with:
logK : write
logE : write
logS : read
logU : read

physical/hardware level:

2 pages of 4 KB each in four different page tables:

logK => page table with: physK : write, physU : ? (should not matter)

logE => page table with: physK : write, physU : write

logS => page table with: physK : write, physU : read

logU => page table with: physK : write, physU : read

??

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <vg8dk0$fdee$1@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:

On 11/3/2024 11:38 AM, Camiel Vanderhoeven wrote:

Arne Vajhøj wrote:

On 11/3/2024 9:06 AM, Camiel Vanderhoeven wrote:

Arne Vajhøj wrote:

x86-64 in long mode only support 2 modes in PTE's, so
VMS x86-64 is a hardware 2 mode OS 4 mode OS - U in ring 3,
S, E and K in ring 0.

Not exactly.

Ring 3 is used for Exec, Super, and User

Ring 0 is used for kernel and for transitions between modes (SWIS)

Running Exec and Super in ring 0 would blow away the separation
(which, I might add, is there more for stability than for security,
before I unintentionally re-start that debate)

You are more afraid that DCL or RMS would step on VMS than
applications would step on DCL or RMS?

No, certainly not. That is why we have a separate set of page tables for
each mode. For instance, a page that has kernel write / exec read
protections is represented by the following PTEs in these 4 sets of page
tables:

kernel mode: S(upervisor) W(riteable)
exec mode: U(ser) R(eadable)
super mode: not present
user mode: not present

So if U code tries to access some data structures requiring
S or E to access, then at the low level it does not
fail for lack of access but it fails for not existing for that mode
(at the higher level it may be translated to a more traditional access >violation)?

In the specific example given by Camiel, yes, this would cause a
fault, which would load the faulting address into %cr2 and force
a trap into the kernel, which could inspect the faulting address
and handle accordingly.

More generally, it depends on the type of access; some data may
be writable writeable in one mode, but only readable in another;
a read access would succeed, a write would fault.

- Dan C.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)