Re: Constant Stack Canaries

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

On 2025-04-04 5:13 p.m., MitchAlsup1 wrote:

On Fri, 4 Apr 2025 3:49:31 +0000, Robert Finch wrote:
>

On 2025-04-03 1:22 p.m., BGB wrote:

-------------------

>
Or, to allow for NOMMU operation, or reduce costs by not having context
switches result in as large of numbers of TLB misses.
>
Also makes the kernel simpler as it doesn't need to deal with each
process having its own address space.

>
Have you seen the MPRV bit in RISCV? Allows memory ops to execute using
the previous mode / address space. The bit just has to be set, then do
the memory op, then reset the bit. Makes it easy to access data using
the process address space.

>
Let us postulate you are running in RISC-V HyperVisor on core[j]
and you want to write into GuestOS VAS and into application VAS
more or less simultaneously.
>

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.
And this has nothing to do with system calls it has to do with
accessing (rather simultaneously) any of the 4 VASs.

Seems to me like you need a MPRV to be more than a single bit
so it could index which layer of the SW stack's VAS it needs
to touch.

>
So, there is a need to be able to go back two or three levels? I suppose
it could also be done by manipulating the stack, although adding an
extra bit may be easier. How often does it happen?

I have no idea, and I suspect GuestOS people don't either.