Path: news.eternal-september.org!eternal-september.org!feeder3.eternal-september.org!usenet.network!news.neodome.net!rocksolid2!i2pn2.org!.POSTED!not-for-mail
From: mitchalsup@aol.com (MitchAlsup1)
Newsgroups: comp.arch
Subject: Re: Constant Stack Canaries
Date: Wed, 9 Apr 2025 00:23:09 +0000
Organization: Rocksolid Light
Message-ID: <f15591af7afc40ebf74588686d9ea34e@www.novabbs.org>
References: <vsbcnl$1d4m5$1@dont-email.me> <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> <ee644124d3b2562986842766af421577@www.novabbs.org> <fgwIP.1525957$eNx6.1219389@fx14.iad> <1a0a4bdf578ae29ba9c2d20f19d0adde@www.novabbs.org> <O0RIP.1475758$SZca.1399925@fx13.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
	logging-data="3729099"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="o5SwNDfMfYu6Mv4wwLiW6e/jbA93UAdzFodw5PEa6eU";
User-Agent: Rocksolid Light
X-Rslight-Site: $2y$10$T2Esdn/EeoR6t1JIpDH2JOojRY985goC6bYKNKjAgT/gzAe1a0INe
X-Rslight-Posting-User: cb29269328a20fe5719ed6a1c397e21f651bda71
X-Spam-Checker-Version: SpamAssassin 4.0.0

On Mon, 7 Apr 2025 14:09:50 +0000, Scott Lurndal wrote:

> mitchalsup@aol.com (MitchAlsup1) writes:
>>On Sun, 6 Apr 2025 14:21:26 +0000, Scott Lurndal wrote:
>>----------------
>>> 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.
>>>
>>> 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.
>>
>>On Sun, 6 Apr 2025 14:32:43 +0000, Scott Lurndal wrote:
>>
>>> That presumes a shared address space between the privilege
>>> levels - which is common for the OS and user-modes.   It's
>>> not common (or particularly useful[*]) at any other privilege
>>> level.
>>
>>So, is this dichotomy because::
>>
>>a) HVs are good enough at virtualizing raw HW that GuestOS
>>   does not need a lot of paravirtualization to be efficient ??
>
> Yes.  Once AMD added Nested Page Tables to SVM and the PCI-SIG
> proposed the SR-IOV capability, paravirtualization became anathema.
>
>>
>>b) GuestOS does not need "that much paravirtualization" to be
>>   efficient anyway.
>
> With modern hardware support, yes.
>
>>
>>c) the kinds of things GuestOS ask HVs to perform is just not
>>   enough like the kind of things user asks of GuestOS.
>
> Yes, that's also a truism.
>
>>
>>d) User and GuestOS evolved in a time before virtualization
>>   and simply prefer to exist as it used to be ??
>
> Typically an OS doesn't know if it is a guest or bare metal.
> That characteristic means that a given distribution can
> operate as either.

Thank you for updating a piece of history apparently I did not
live through !!