Re: x86S Specification

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.