Re: Constant Stack Canaries

On 4/16/2025 2:13 PM, MitchAlsup1 wrote:

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

I think you could gain a tiny amount of efficiency if the OS (super) allowed the user to set up handle certain classes of exceptions, e.g. divide faults) itself rather than having to go through the super.
--
  - Stephen Fuld
(e-mail address disguised to prevent spam)