Re: Constant Stack Canaries

On Wed, 16 Apr 2025 14:07:36 +0000, Scott Lurndal wrote:

mitchalsup@aol.com (MitchAlsup1) writes:

---------snip-----------

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

>
ARM, for example, splits the per-core interrupt  priority range into
halves
- one half is assigned to the secure monitor and the other is assigned
to the
non-secure software running on the core.

Thus, my predilection for 64-priority levels (rather than ~8 as
suggested
by another participant) allows for this distribution of priorities
across
layers in the SW stack at the discretion of trustable-SW.

                                          Early hypervisors would field
all
non-secure interrupts and either handle them itself or inject them into
the guest.    The first ARM64 cores would field all interrupts in the HV
and the int controller had special registers the HV could use to inject
interrupts
into the guest.    The overhead was not insignifcant, so they added
a mechanism to allow some interrupts to be directly fielded by the
guest itself - avoiding the round trip through the HV on every interrupt
(called virtual LPIs).

Given 4 layers in the stack {Secure, Hyper, Super, User} and we have
interrupts targeting {Secure, Hyper, Super}, do we pick up any liability
or do we gain flexibility by being able to target interrupts directly to
{user} ?? (the 4th element).
Roughly: HW maintains 4 copies of state and generally indexes state
with a 2-bit value, and the "structure" of thread-header is identical
between layers; thus, indexing down to {user} falls out for free.
{{But I could be off my rocker...again}}