Re: Privilege Levels Below User

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...