[Info-vax] x86S Specification

[Dan Cross]

In article <vg8dk0$fdee$1 at dont-email.me>,
Arne Vajhøj  <arne at 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.