Re: Stacks, was Segments

On Thu, 6 Feb 2025 18:51:12 +0000, EricP wrote:

MitchAlsup1 wrote:

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

-----------------------------------

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

In this case, HV needs to know its limitations and not access the
device nor the secure memory. Probably by taking the memory out
of the pool it "does normal stuff with" and take the device out
of its list of accessible devices (at least for a while).

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?

I am thinking more like SR-IOV where HV loans a virtual device to a
Guest OS, and Guest OS performs the I/O request, HV and SM are only
there to deal with HV page faults and device errors. If a HV page
fault occurs (which it will) a pretty secure corner of HV will
construct a PTE mapping that/those page[s] only to page the missing
page into memory so I/O can proceed. HV will then have to dismantle
said mapping after the page arrives to restart device DMA.

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

Yes, exactly. No normal access to the page, only swap access is
allowed--although this can be alleviated by not paging secure
memory::then HV just knows nothing about that/those pages until
the process terminates where it can put the pages back in the
normal pool after cleaning them out.