Re: Constant Stack Canaries

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.
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.
For example:: GuestOS DIs, and HV takes a page fault from GuestOS;
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.
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.

>
b) GuestOS does not need "that much paravirtualization" to be
  efficient anyway.

>
With modern hardware support, yes.
>

>
c) the kinds of things GuestOS ask HVs to perform is just not
  enough like the kind of things user asks of GuestOS.

>
Yes, that's also a truism.
>

>
d) User and GuestOS evolved in a time before virtualization
  and simply prefer to exist as it used to be ??

>
Typically an OS doesn't know if it is a guest or bare metal.
That characteristic means that a given distribution can
operate as either.