Path: ...!eternal-september.org!feeder2.eternal-september.org!panix!.POSTED.spitfire.i.gajendra.net!not-for-mail
From: cross@spitfire.i.gajendra.net (Dan Cross)
Newsgroups: comp.os.vms
Subject: Re: x86S Specification
Date: Mon, 4 Nov 2024 01:08:45 -0000 (UTC)
Organization: PANIX Public Access Internet and UNIX, NYC
Message-ID: <vg96qt$ar7$1@reader1.panix.com>
References: <ves555$2uh6n$1@dont-email.me> <vg80uo$d0cf$1@dont-email.me> <8e6dec20-d4b8-7301-30f0-8d92eb8e79cc@vmssoftware.com> <672813c5$0$719$14726298@news.sunsite.dk>
Injection-Date: Mon, 4 Nov 2024 01:08:45 -0000 (UTC)
Injection-Info: reader1.panix.com; posting-host="spitfire.i.gajendra.net:166.84.136.80";
	logging-data="11111"; mail-complaints-to="abuse@panix.com"
X-Newsreader: trn 4.0-test77 (Sep 1, 2010)
Originator: cross@spitfire.i.gajendra.net (Dan Cross)
Bytes: 4145
Lines: 87

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.