Re: Privilege Levels Below User

John Savard wrote:

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.

Most of the miscreations have to do with allowing microarchitectural state to be come visible through a high precision timing mechanism,
not with the skirting of privilege.

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.

In My 66000, the Monitor, Hypervisor, Supervisor, and guest can
share the dynamic libraries contining no privileged instructions.
And since there is only 1 such instruction it is easy to check.
However, a Pthread can transfer control to another Pthread without
privilege in a single instruction.

The first reduced-privilege state would not allow any branch
instructions, particularly conditional branches.

Are My 66000 predication shadows considered "branching" since they
do not alter where the Fetch end of the pipeline is working??
Are My 66000 Switch instructions considered branches ?? since the
transfer table is in .text and relative to the current switch
instruction?
Are Supervisor Calls "brnches" since they go to controlled entry points??
Are Supervisor Returns "branches" since they to to controlled return points ??

The second, in addition, would not allow any access to memory, only
allowing access to registers.

To use these states to aid in security, more is required.

For one thing, blocks of memory would need to be able to be marked as
not only containing code or data, but as containing code that runs at
one of these reduced privilege levels.

How are you going to perform elementary functions {SIN, COS, EXP, LOG}?

And then comes the payaoff: a block of memory could be marked as
writeable, but yet containing executable code, for things like
just-in-time compilation...

A C compiler is an application running in a different process. Why
is a JIT "not like that" ??
                              but as only containing code at one of

these reduced privilege levels. Thus preventing the generation of code
containing branches or memory accesses, as desired, while allowing the
generation of computational sequences.

John Savard