Re: Stacks, was Segments

On Fri, 7 Feb 2025 13:57:51 +0000, Scott Lurndal wrote:

mitchalsup@aol.com (MitchAlsup1) writes:

On Thu, 6 Feb 2025 20:06:31 +0000, Stephen Fuld wrote:
>

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

MitchAlsup1 wrote:

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

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?

>
I/O MMU does not see the device commands containing the sector on
the disk to be accessed, Mostly, CPUs write directly to the CRs
of the device to start a command, bypassing I/O MMU as raw data.

>
That is indeed the case.   The IOMMU is on the inbound path
from the PCIe controller to the internal bus/mesh structure.
>
Note that there is a translation on the outbound path from
the host address space to the PCIe memory space - this is
often 1:1, but need not be so.   This translation happens
in the PCIe controller when creating the a TLP that contains
an address before sending the TLP to the endpoint.   Take

Is there any reason this cannot happen in the core MMU ??
Guest OS uses a virtual device address given to it from HV.
HV sets up the 2nd nesting of translation to translate this
to "what HostBridge needs" to route commands to device control
registers. The handoff can be done by spoofing config space
of having HV simply hand Guest OS a list of devices it can
discover/configure/use.

an AHCI controller, for example, where the only device
BAR is 32-bits; if a host wants to map the AHCI controller
at a 64-bit address, the controller needs to map that 64-bit
address window into a 32-bit 3DW TLP to be sent to the endpoint
function.

This is one of the reasons My 66000 architecture has a unique
MMI/O address space--you can setup a 32-bit BAR to put a
page of control registers in 32-bit address space without
conflict. {{If I understand correctly}} Core MMU, then,
translates normal device virtual control register addresses
such that the request is routed to where the device is looking
{{which has 32 high order bits zero.}}
On the other hand--it would take a very big system indeed to
overflow the 32-bit MMI/O space, although ECAM can access
42-bit device CR MMI/O space.

The ARM SMMU is split into two - one that translates inbound
addresses that are not marked secure by the endpoint, and
one that translates addresses that are marked secure by the
endpoint (or by some host bridge between the endpoint and
the host internal bus structures which is configured by
the secure software).  The secure side is managed by the
secure monitor;  the non-secure side by the HV or bare-metal
OS.
>

>
In my block diagrams of HostBridge, I show I/O MMU only on the
receiving side of PCIe transport links. all the outbound traffic
has already been translated by a core MMMU, unless one allows
a device to send commands to another device.
>
I/O MMU sees the virtual address of where DMA is accessing, translating
accordingly.
>
I/O MMU sees the virtual address of MSI-X interrupts, page faults and
errors.

>
By page faults, I assume you're referring to the PCIe PRI (Page Request
Interface) and ATS capabilities.
>

>

                                                       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.

>
Protecting a process without privilege from a process WITH privilege
requires more than a little trust in the privileged process(s).
This is why there is a Secure Monitor over HyperVisor to take HV out
of the control loop for "secure stuff". By assuming the duties of
HV wrt accessing unprivileged memory of storage, SM minimizes the
footprint where trust is required.

>
ARM has a "RM" (Realm Monitor) that sits between the HV and the SM
to manage memory visiblity and security.
>
https://developer.arm.com/documentation/den0127/0200/Software-components/Realm-Management-Monitor
>

>

                             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.

>
Assuming the file is not secured via other means such as cryptography.