Path: ...!eternal-september.org!feeder2.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: =?UTF-8?Q?Arne_Vajh=C3=B8j?= <arne@vajhoej.dk>
Newsgroups: comp.os.vms
Subject: Re: x86S Specification
Date: Sun, 3 Nov 2024 12:58:25 -0500
Organization: A noiseless patient Spider
Lines: 39
Message-ID: <vg8dk0$fdee$1@dont-email.me>
References: <ves555$2uh6n$1@dont-email.me> <ves6gu$2umgd$1@dont-email.me>
 <5acb70a334dba080ecce579c4bf18c3edc448e7c.camel@munted.eu>
 <veteh7$38vcj$1@dont-email.me> <vg800m$cvhp$1@dont-email.me>
 <vg80uo$d0cf$1@dont-email.me>
 <8e6dec20-d4b8-7301-30f0-8d92eb8e79cc@vmssoftware.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 03 Nov 2024 18:58:25 +0100 (CET)
Injection-Info: dont-email.me; posting-host="1e9abb83edff08986972949a50ffae06";
	logging-data="505294"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18IVJHvYQks/QQUHEZszVIgR0MInvgs308="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:gh2Jm8M4wkGkmzvZrjBK1zUYIvE=
In-Reply-To: <8e6dec20-d4b8-7301-30f0-8d92eb8e79cc@vmssoftware.com>
Content-Language: en-US
Bytes: 2664

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