Re: Constant Stack Canaries

On Tue, 15 Apr 2025 14:02:37 +0000, Scott Lurndal wrote:

mitchalsup@aol.com (MitchAlsup1) writes:

On Mon, 7 Apr 2025 14:09:50 +0000, Scott Lurndal wrote:
>

mitchalsup@aol.com (MitchAlsup1) writes:

On Sun, 6 Apr 2025 14:21:26 +0000, Scott Lurndal wrote:
----------------

When the exception (in this case an upcall to a more privileged
regime) occurs, the saved state register/stack word should contain the
prior privilege level.   The hypervisor will know from that whether
the upcall was from the guest OS or a guest Application.
>
Note that on ARM, there are restrictions on upcalls to
more privileged regimes - generally a particular regime
can only upcall the next higher privileged regime, so
the user app can only upcall the GuestOS,  the guest OS can only
upcall the HV and the HV is the only regime that can
upcall the secure monitor.

>
On Sun, 6 Apr 2025 14:32:43 +0000, Scott Lurndal wrote:
>

That presumes a shared address space between the privilege
levels - which is common for the OS and user-modes.   It's
not common (or particularly useful[*]) at any other privilege
level.

>
So, is this dichotomy because::
>
a) HVs are good enough at virtualizing raw HW that GuestOS
  does not need a lot of paravirtualization to be efficient ??

>
Yes.  Once AMD added Nested Page Tables to SVM and the PCI-SIG
proposed the SR-IOV capability, paravirtualization became anathema.

>
Ok, back to Dan Cross:: (with help from Scott)
>
If GuestOS wants to grab and hold onto a lock/mutex for a while
to do some critical section stuff--does GuestOS "care" that HV
can still take an interrupt while GuestOS is doing its CS thing ??
since HV is not going to touch any memory associated with GuestOS.

>
Generally, the Guest should execute "as if" it were running on
Bare Metal.  Consider an intel/amd processor running a bare-metal
operating system that takes an interrupt into SMM mode;  from the
POV of a guest, an HV interrupt is similar to an SMM interrupt.
>
If the SMM, Secure Monitor or HV modify guest memory in any way,
all bets are off.

Yes, but we have previously established HV does its virtualization
without touching GuestOS memory. {Which is why I used page fault as
the example.}

>
In effect, I am asking is Disable Interrupt is SW-stack-wide or only
applicable to the current layer of the SW stack ?? One can equally
use SW-stack-wide to mean core-wide.

>
Current layer of the privilege stack.   If there is a secure monitor
at a more privileged level than the HV, it can take interrupts in a
manner similar to the legacy SMM interupts.  Typically there will
be independent periodic timer interrupts in the Guest OS, the HV, and
the secure monitor.

This agrees with the RISC-V approach where each layer in the stack
has its own Interrupt Enable configuration. {Which is what lead to
my questions}.
However, many architectures have only a single control bit for the
whole core--which is shy I am trying to get a complete understanding
of what is required and what is choice. That there is some control
is (IS) required--how many seems to be choice at this stage.
Would it be unwise of me to speculate that a control at each layer
is more optimal, or that the critical section that is delayed due
to "other stuff needing to be handled" should have taken precedent.
Anyone know of any literature where this was simulate or measured ??

>
For example:: GuestOS DIs, and HV takes a page fault from GuestOS;

>
Note that these will be rare and only if the HV overcommits physical
memory.
>

makes the page resident and accessible, and allows GuestOS to run
from the point of fault. GuestOS "sees" no interrupt and nothing
in GuestOS VAS is touched by HV in servicing the page fault.

>
The only way that the guest OS or guest OS application can detect
such an event is if it measures an affected load/store - a covert
channel.  So there may be security considerations.

Damn that high precision clock .....
Which also leads to the question of should a Virtual Machine have
its own virtual time ?? {Or VM and VMM share the concept of virtual
time} ??

>
Now, sure that lock is held while the page fault is being serviced,
and the ugly head of priority inversion takes hold. But ... I am ni
need of some edumacation here.

>
Priority inversion is only applicable within a privilege level/ring.
Interrupts to a higher privilege level cannot be masked by an active
interrupt at a lower priority level.

So, if core is running HyperVisor at priority 15 and a user interrupt
arrives at a higher priority but directed at GuestOS (instead of HV)
does::
a) HV continue leaving higher priority interrupt waiting.
b) switch back to GuestOS for higher priority interrupt--in such
. a way that when GuestOS returns from interrupt HV takes over
. from whence it left.
This is really a question of what priority means across the entire
SW stack--and real-time versus Linux may have different answers on
this matter.

The higher privilege level must not unilaterally modify guest OS or
application state.

Given the almost complete lack of shared address spaces in a manner
where pointers can be passed between, there is almost nothing an HV
can do to a GuestOS VAS unless GuestOS has ask for a HV service via
paravirtualization entry point.