Re: Constant Stack Canaries

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? 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 got the thought to use the three bits a bit differently.
111 = use current mode
110 = use mode from stack
100 = debug? mode
011 = secure (machine) mode
010 = hypervisor mode
001 = supervisor mode
000 = user/app mode
I was just using inline code to select the proper address space. But if it is necessary to dig around to figure the mode, it may turn into a subroutine call.