Re: Constant Stack Canaries

On 2025-04-06 10:21 a.m., Scott Lurndal wrote:

Robert Finch <robfi680@gmail.com> writes:

On 2025-04-05 2:31 p.m., Scott Lurndal wrote:

mitchalsup@aol.com (MitchAlsup1) writes:

On Sat, 5 Apr 2025 3:45:51 +0000, Robert Finch wrote:
>

>

Would not writing to the GuestOs VAS and the application VAS be the
result of separate system calls? Or does the hypervisor take over for
the GuestOS?

>
Application has a 64-bit VAS
GusetOS has a 64-bit VAS
HyprVisor has a 64-bit VAS
and so does
Securte has a 64-bit VAS
>
So, we are in HV and we need to write to guestOS and to Application
but we have only 1-bit of distinction.

>
On ARM64, when the HV needs to write to guest user VA or guest PA,
the SMMU provides an interface the processor can use to translate
the guest VA or Guest PA to the corresponding system physical address.
Of course, there is a race if the guest OS changes the underlying
translation tables during the upcall to the hypervisor or secure
monitor, although that would be a bug in the guest were it so to do,
since the guest explicitly requested the action from the higher
privilege level (e.g. HV).
>
Arm does have a set of load/store "user" instructions that translate
addresses using the unprivileged (application) translation tables.  There's
also a processor state bit (UAO - User Access Override) that can
be set to force those instructions to use the permissions associated
with the current processor privilege level.
>
Note that there is a push by all vendors to include support
for guest 'privacy', such that the hypervisor has no direct
access to memory owned by the guest, or where the the guest
memory is encrypted using a key the hypervisor or secure monitor
don't have access to.
>

Okay,
>
I was interpreting RISCV specs wrong. They have three bits dedicated to
this. 1 is an on/off and the other two are the mode to use. I am left
wondering how it is determined which mode to use. If the hypervisor is
passed a pointer to a VAS variable in a register, how does it know that
the pointer is for the supervisor or the user/app?

 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.
 

Yes, Q+ works that way, I think RISCV does as well. Q+ stacks the PC and SR on an internal stack which is basically a shift register. The TOS is visible as a CR. The mode is state saved in the SR. Interrupts and exceptions do not have to store the state in memory. The far end of the stack is hard coded to do a reset if the stack underflows.

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.
 

Allows two directional virtualization I think. Q+ has all exceptions and interrupts going to the secure monitor, which can then delegate it back to a lower level.

It's why I assumed it
found the mode from the stack. Those two select bits have to set
somehow. It seems like extra code to access the right address space.'

 I haven't spent much time with RISC-V, but surely the processor
has a state register that stores the current mode, and which
must be preserved over exceptions/upcalls, which would require
that they be recorded in an exception syndrome register for
restoration when the upcall returns.