Re: Stacks, was Segments

On 2/6/2025 10:51 AM, EricP wrote:

MitchAlsup1 wrote:

On Thu, 6 Feb 2025 16:41:45 +0000, EricP wrote:
>

MitchAlsup1 wrote:

On Wed, 5 Feb 2025 19:55:14 +0000, EricP wrote:
>

EricP wrote:

>
=====================================
For the present day we would want REW access control.
Naively this would require 4*3 = 12 bits in each PTE.
>
If apply the rules:
- we only need a meaningful subset of combinations: na, R, RE, RW, REW.
- no higher priv level can have less access than a lower priv level.
- we can save 1 combo because all 4 priv levels = na is redundant
  with the PTE Present bit being clear.
>
we can get this all down to a 4-bit PTE field:
>
Usr Sup Exc Krn
--- --- --- ---
na  na  na  R
na  na  na  RE
na  na  na  RW
na  na  na  REW
na  na  R   R
na  na  RE  RE
....
R   R   R   R
....
REW REW REW REW
>
The core's (thread's) privilege mode would enable access to the pages.
The PTE's access control field, which is derived from the kind of
mapped memory section, would not have to change between different
threads.

>
Or if you want the flexibility to choose your own REW combinations,
the 4-bit PTE access control field is an index to a 16 entry array
of 12-bit values for the four privilege levels.
>
That's better because then the OS can decide how it wants
the different memory sections and thread to behave and
removes the strict hardwired hierarchy of the prior rules.
>
The next problem though might be finding 4 bits in the PTE.

>
Another PTE bit I can find. Placing the 16×12 vector is more difficult,
even when I position it as 4 places of 16×3.

>
I don't understand what you said.
The 4-bit Access Control (AC) field is in the PTE.

>
Currently, PTE uses a 3-bit access control field, and PTE has
2-bits spare. So making access control larger is easy.
>

The 16 row x 12-bit AC-to-allowed-access programmable HW lookup table
is in the MMU.

>
How does 16×12 get to the MMU (or I/O MMU) ?? in such a way that super
cannot see things Hyper can see and the same with secure. So, somewhere
in the various control blocks I need to find space without changing
the overall use pattern of the control blocks and tables. Which is
why I alluded to 4×16×3 each interpretation of the 4-bit access control
is stored it its own natural place. It also means each layer can apply
its own interpretation (mapping).

 Its just an SRAM loaded by the boot ROM before the Hypervisor boots.
The super-secure version of boot ROM loads a table with values
(Sandbox, User, Kernel, Hypervisor):
 Snd Usr Krn Hyp
na  na  na  R
na  na  na  RE
na  na  na  RW
na  na  na  REW
na  na  R   na
na  na  RE  na
na  na  RW  na
na  na  REW na
na  R   R   na
na  RE  RE  na
...
REW REW REW na
 which grants mode 0 (Hyp) no direct RW access to any memory outside itself.
Boot ROM sets an optional table lock so even hypervisor cannot later
grant itself access permission to less priv memory by changing the table.
 

The core's 2-bit mode selects-muxes one of the 3-bit allowed access
fields from the indexed 12-bits to extract the 3 R-E-W bits.

>
That much is straightforward.
>

The 2-bit mode comes from the LD/ST uOp, which was set to the mode
active when the instruction was decoded (so it can pipeline mode
changes).

>
Yes, core-state index follows the memref down the pipe.
Core-state index is written into MMI/O/device control block for the
DMA portion of a command, other CD indexes are associated with I/O
page faults and device errors.

 Not sure how this would work with device IO and DMA.
Say a secure kernel that owns a disk drive with secrets that even the HV
is not authorized to see (so HV operators don't need Top Secret clearance).
The Hypervisor has to pass to a hardware device DMA access to a memory
frame that it has no access to itself. How does one block the HV from
setting the IOMMU to DMA the device's secrets into its own memory?
 Hmmm... something like: once a secure HV passes a physical frame address
to a secure kernel then it cannot take it back, it can only ask that
kernel for it back. Which means that the HV looses control of any
core or IOMMU PTE's that map that frame until it is handed back.
 That would seem to imply that once an HV gives memory to a secure
guest kernel that it can only page that guest with its permission.
Hmmm...

I am a little confused here.  When you talk about I0MMU addresses, are you talking about memory addresses or disk addresses?  ISTM that protecting memory of lower privileged programs is useless if a higher privileged program can force a page out to disk, then can read the data from the disk drive itself.  Of course, the same is true for data written to disk by a lesser privileged program.  If the higher privileged program can read the file, then it can compromise security.
--
  - Stephen Fuld
(e-mail address disguised to prevent spam)