Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: BGB <cr88192@gmail.com>
Newsgroups: comp.arch
Subject: Re: Privilege Levels Below User
Date: Sat, 8 Jun 2024 13:45:51 -0500
Organization: A noiseless patient Spider
Lines: 115
Message-ID: <v428v9$2o803$1@dont-email.me>
References: <jai66jd4ih4ejmek0abnl4gvg5td4obsqg@4ax.com>
 <Z9I8O.13$2JEf.11@fx14.iad> <5h%8O.4327$wDZ.776@fx48.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 08 Jun 2024 20:47:06 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="51e60a99c6f849f26f298e0d84d4cfe3";
	logging-data="2891779"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18u42d1Bx/KUILSGn8Him0ybTZ1y9DA+Ok="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:DBkyhX9anpLoZ58z2ODLyG1HKeo=
In-Reply-To: <5h%8O.4327$wDZ.776@fx48.iad>
Content-Language: en-US
Bytes: 6005

On 6/8/2024 11:01 AM, EricP wrote:
> Scott Lurndal wrote:
>> John Savard <quadibloc@servername.invalid> writes:
>>> This may be a silly idea... but it seems to be the sort of thing that
>>> current concerns about computer security may be calling for.
>>>
>>> It is typical for computers to have a privileged mode of operation,
>>> wherein I/O operations and certain special changes to the state of the
>>> computer are allowed that are barred to normal computational  tasks.
>>>
>>> For various reasons, miscreants have not been completely foiled by the
>>> existence of this feature.
>>>
>>> Some types of instruction that are required for normal computation are
>>> still, to a certain extent, potentially harmful.
>>>
>>> So I am thinking it might be useful to have, for example, two states
>>> less privileged than the user state, and some mechanism for user
>>> programs to call subroutines which are in that state until they return
>>> - the return instruction being limited, sort of like a supervisor
>>> call, so it can only return in a proper manner.
>>
>> There are already more than five security rings in most
>> processors.
>>
>> Intel:   Ring 3, Ring 2 (unused), Ring 1(unused), Ring 0, VMX, 
>> Enclave,  SMM
>> AMD:     Ring 3, Ring 2 (unused), Ring 1(unused), Ring 0, SVM, SMM
>> ARM64:   Realm Monitor, EL3 (Secure monitor), EL2(Hypervisor), EL1 
>> (Kernel), EL0 (user)
> 
> VAX had 4 modes, User, Supervisor, Executive, Kernel.
> VMS used Super for debugger and the command language DCL,
> Exec was mostly for the file system.
> Kernel was for the core of the OS.
> 
> What they found that not only do they not need 4 levels,
> it was a pointless overhead to have to constantly switch between them.
> (There is a pretty high penalty to switching modes, copying in args,
> validating args, doing something usually simple, then switching back,
> when it is all the OS's code anyway.)
> 
> I don't know what privileges Unix on VAX used but it was
> probably 2 levels because PDP-11 had only 2 levels.
> 
> Alpha had 3 levels, User, Supervisor, and a higher third mode called
> PAL for Privileged Architecture Library. It was supposed to be thought
> of like microcode, privileged subroutines. Then PAL mode was used to
> emulate the 4 levels that VMS expected when they ported it.
> 
> (I think PAL mode was a way to patent a feature that made the
> ISA impossible to copy without their permission,
> and therefore someone can't take DEC's executables and run them
> on a clone processor, like what happened to IBM with Amdahl.)
> 
> WinNT was written to be portable so the lowest common denominator
> is 2 levels, User and Super, and everything worked just fine.
> 

In my case, there are 3 modes:
   User, Supervisor, Interrupt.

Interrupt is used for interrupt handlers. Effectively behaves like 
Supervisor but with virtual address translation disabled (and with the 
SP and SSP registers swapping places).


My thinking was that VUGID/ACL checking could be used within User and 
Supervisor modes to offer additional memory protection.

So, say, creating a thread that is effectively sandboxed and can't 
access any memory outside a small region (in user mode), should be possible.


Granted, it would not change which ISA level features are available in 
the base modes.

Though, there are some instructions which are currently allowed in user 
mode but which it could make sense to trap in some contexts, such as 
CPUID, or potentially just parts of CPUID, ...

Say, for example, CPUID has several pieces of information available:
   CPU type and features;
   Microsecond timer (local);
   Clock cycle timer;
   Hardware RNG;
   ...

In various contexts, it may be reasonable to want to trap and emulate 
some of these while still allowing others to be unhindered.

Though, the time returned by the CPUID microsecond timer is not 
currently the same as the one given by "TK_GetTimeUS()", where the 
latter effectively gives a 64-bit value (conceptually) representing the 
number of microseconds since 1/1/1970; though with the kernel currently 
assuming that its build-time is the starting time for the clock (and 
none of the FPGA boards support a hardware clock, and one would need 
internet access to use NTP, ...).

A 64-bit value in microseconds can express around +/- 300k years, which 
should be plenty.

A 64-bit value expressed in seconds could express values relative to the 
current age of the universe, but this is likely unnecessary for most 
purposes, and ability to express fractions of a second is likely more 
useful than the ability to express the age of the universe.


Granted, one could use a 128-bit value, and have both (and in 
picoseconds if they wanted). But, this would be overkill.

Or, go extra overkill, and use 256 bits, to express the current age of 
the universe in Planck units...