Path: ...!weretis.net!feeder9.news.weretis.net!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail
From: mitchalsup@aol.com (MitchAlsup1)
Newsgroups: comp.arch
Subject: Re: Constant Stack Canaries
Date: Sat, 5 Apr 2025 23:11:00 +0000
Organization: Rocksolid Light
Message-ID: <7ea7be2799c9dac8cef1c4b9c33922b7@www.novabbs.org>
References: <vsbcnl$1d4m5$1@dont-email.me> <62b5c4a25d917c5bab64a815189de826@www.novabbs.org> <vshf6a$3smcv$1@dont-email.me> <21397906a7a77c2d43191fdaab98a3c9@www.novabbs.org> <jwv4iz75l6k.fsf-monnier+comp.arch@gnu.org> <vsidun$sput$2@dont-email.me> <jwvtt752vg1.fsf-monnier+comp.arch@gnu.org> <vsmg8a$16gr3$1@dont-email.me> <vsnksc$2fkk9$1@dont-email.me> <6a77fabdb64f59e4497ef3353d747441@www.novabbs.org> <vsq91i$18k1q$1@dont-email.me> <760b3834d1202502f5f63e52b51cfdc8@www.novabbs.org> <kGeIP.467285$d51.395138@fx46.iad> <vss913$3b1ga$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
	logging-data="3297696"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="o5SwNDfMfYu6Mv4wwLiW6e/jbA93UAdzFodw5PEa6eU";
User-Agent: Rocksolid Light
X-Spam-Checker-Version: SpamAssassin 4.0.0
X-Rslight-Posting-User: cb29269328a20fe5719ed6a1c397e21f651bda71
X-Rslight-Site: $2y$10$neqPfgwK4utyKoHgEcQ7eOM09WucUykdW7YlDFCyxQeqNDeEWUrbq
Bytes: 4589
Lines: 71

On Sat, 5 Apr 2025 21:57:50 +0000, Robert Finch wrote:

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

More interesting the the concept that there are multiple HVs that
have been virtualized--in this case the sender of the address may
think it has HV privilege but is currently operating as if it only
has GuestOS privilege. ...

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

All the machines I have used/designed/programmed in the past use 000
as highest privilege and 111 as lowest.