Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch > #111375 > unrolled thread

Constant Stack Canaries

Back to article view | Back to comp.arch

Contents

  Constant Stack Canaries Robert Finch <robfi680@gmail.com> - 2025-03-30 08:16 -0400
    Re: Constant Stack Canaries BGB <cr88192@gmail.com> - 2025-03-30 12:47 -0500
      Re: Constant Stack Canaries mitchalsup@aol.com (MitchAlsup1) - 2025-03-30 20:14 +0000
        Re: Constant Stack Canaries Robert Finch <robfi680@gmail.com> - 2025-03-30 21:26 -0400
        Re: Constant Stack Canaries BGB <cr88192@gmail.com> - 2025-03-31 01:34 -0500
        Re: Constant Stack Canaries Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-03-31 09:04 -0700
          Re: Constant Stack Canaries BGB <cr88192@gmail.com> - 2025-03-31 12:17 -0500
            Re: Constant Stack Canaries Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-03-31 10:57 -0700
            Re: Constant Stack Canaries mitchalsup@aol.com (MitchAlsup1) - 2025-03-31 18:07 +0000
              Re: Constant Stack Canaries BGB <cr88192@gmail.com> - 2025-03-31 13:56 -0500
                Re: Constant Stack Canaries mitchalsup@aol.com (MitchAlsup1) - 2025-03-31 20:52 +0000
                  Re: Constant Stack Canaries Robert Finch <robfi680@gmail.com> - 2025-04-01 00:58 -0400
                    Re: Constant Stack Canaries mitchalsup@aol.com (MitchAlsup1) - 2025-04-01 18:51 +0000
                      Re: Constant Stack Canaries Robert Finch <robfi680@gmail.com> - 2025-04-01 18:06 -0400
                        Re: Constant Stack Canaries mitchalsup@aol.com (MitchAlsup1) - 2025-04-01 23:24 +0000
                          Re: Constant Stack Canaries Robert Finch <robfi680@gmail.com> - 2025-04-01 20:07 -0400
                            Re: Constant Stack Canaries mitchalsup@aol.com (MitchAlsup1) - 2025-04-02 01:47 +0000
                            Re: Constant Stack Canaries mitchalsup@aol.com (MitchAlsup1) - 2025-04-04 21:07 +0000
                    Re: Constant Stack Canaries BGB <cr88192@gmail.com> - 2025-04-01 16:21 -0500
                      Re: Constant Stack Canaries Robert Finch <robfi680@gmail.com> - 2025-04-01 18:19 -0400
                        Re: Constant Stack Canaries BGB <cr88192@gmail.com> - 2025-04-01 23:04 -0500
                  Re: Constant Stack Canaries BGB <cr88192@gmail.com> - 2025-04-01 14:34 -0500
                    Re: Constant Stack Canaries mitchalsup@aol.com (MitchAlsup1) - 2025-04-01 23:21 +0000
                      Re: Constant Stack Canaries Stefan Monnier <monnier@iro.umontreal.ca> - 2025-04-01 22:55 -0400
                        Re: Constant Stack Canaries BGB <cr88192@gmail.com> - 2025-04-01 23:19 -0500
                          Re: Constant Stack Canaries Stefan Monnier <monnier@iro.umontreal.ca> - 2025-04-03 10:09 -0400
                            Re: Constant Stack Canaries BGB <cr88192@gmail.com> - 2025-04-03 12:22 -0500
                              Re: Constant Stack Canaries Robert Finch <robfi680@gmail.com> - 2025-04-03 23:49 -0400
                                Re: Constant Stack Canaries BGB <cr88192@gmail.com> - 2025-04-04 12:41 -0500
                                Re: Constant Stack Canaries mitchalsup@aol.com (MitchAlsup1) - 2025-04-04 21:13 +0000
                                  Re: Constant Stack Canaries Robert Finch <robfi680@gmail.com> - 2025-04-04 23:45 -0400
                                    Re: Constant Stack Canaries mitchalsup@aol.com (MitchAlsup1) - 2025-04-05 16:37 +0000
                                      Re: Constant Stack Canaries scott@slp53.sl.home (Scott Lurndal) - 2025-04-05 18:31 +0000
                                        Re: Constant Stack Canaries Robert Finch <robfi680@gmail.com> - 2025-04-05 17:57 -0400
                                          Re: Constant Stack Canaries mitchalsup@aol.com (MitchAlsup1) - 2025-04-05 23:11 +0000
                                          Re: Constant Stack Canaries scott@slp53.sl.home (Scott Lurndal) - 2025-04-06 14:21 +0000
                                            Re: Constant Stack Canaries Robert Finch <robfi680@gmail.com> - 2025-04-06 15:01 -0400
                                              Re: Constant Stack Canaries scott@slp53.sl.home (Scott Lurndal) - 2025-04-07 14:04 +0000
                                        Re: Constant Stack Canaries mitchalsup@aol.com (MitchAlsup1) - 2025-04-05 23:06 +0000
                                          Re: Constant Stack Canaries scott@slp53.sl.home (Scott Lurndal) - 2025-04-06 14:32 +0000
                                            Re: Constant Stack Canaries mitchalsup@aol.com (MitchAlsup1) - 2025-04-07 00:51 +0000
                                              Re: Constant Stack Canaries scott@slp53.sl.home (Scott Lurndal) - 2025-04-07 14:09 +0000
                                                Re: Constant Stack Canaries mitchalsup@aol.com (MitchAlsup1) - 2025-04-09 00:23 +0000
                                                Re: Constant Stack Canaries mitchalsup@aol.com (MitchAlsup1) - 2025-04-15 00:43 +0000
                                                  Re: Constant Stack Canaries scott@slp53.sl.home (Scott Lurndal) - 2025-04-15 14:02 +0000
                                                    Re: Constant Stack Canaries mitchalsup@aol.com (MitchAlsup1) - 2025-04-15 20:46 +0000
                                                      Re: Constant Stack Canaries scott@slp53.sl.home (Scott Lurndal) - 2025-04-16 14:07 +0000
                                                        Re: Constant Stack Canaries mitchalsup@aol.com (MitchAlsup1) - 2025-04-16 21:13 +0000
                                                          Virtualization layers (was: Constant Stack Canaries) Stefan Monnier <monnier@iro.umontreal.ca> - 2025-04-16 17:48 -0400
                                                            Re: Virtualization layers mitchalsup@aol.com (MitchAlsup1) - 2025-04-16 22:12 +0000
                                                            Re: Virtualization layers (was: Constant Stack Canaries) scott@slp53.sl.home (Scott Lurndal) - 2025-04-17 00:49 +0000
                                                          Re: Constant Stack Canaries Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-04-16 15:26 -0700
                                                            Re: Constant Stack Canaries scott@slp53.sl.home (Scott Lurndal) - 2025-04-17 00:57 +0000
                                                              Re: virtualization, Constant Stack Canaries John Levine <johnl@taugh.com> - 2025-04-17 01:04 +0000
                                                                Re: virtualization, Constant Stack Canaries Stefan Monnier <monnier@iro.umontreal.ca> - 2025-04-16 21:07 -0400
                                                                Re: virtualization, Constant Stack Canaries Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-04-16 23:30 -0700
                                                                Re: virtualization, Constant Stack Canaries scott@slp53.sl.home (Scott Lurndal) - 2025-04-17 13:32 +0000
                                                                Re: virtualization, Constant Stack Canaries mitchalsup@aol.com (MitchAlsup1) - 2025-04-17 18:22 +0000
                                                                  Re: virtualization, Constant Stack Canaries scott@slp53.sl.home (Scott Lurndal) - 2025-04-17 20:10 +0000
                                                                    Re: virtualization, Constant Stack Canaries mitchalsup@aol.com (MitchAlsup1) - 2025-04-17 21:45 +0000
                                                          Re: Constant Stack Canaries scott@slp53.sl.home (Scott Lurndal) - 2025-04-17 00:47 +0000
                      Re: Constant Stack Canaries BGB <cr88192@gmail.com> - 2025-04-02 00:43 -0500

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#111444

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

b) GuestOS does not need "that much paravirtualization" to be
   efficient anyway.

c) the kinds of things GuestOS ask HVs to perform is just not
   enough like the kind of things user asks of GuestOS.

d) User and GuestOS evolved in a time before virtualization
   and simply prefer to exist as it used to be ??

[toc] | [prev] | [next] | [standalone]

#111446

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.

[toc] | [prev] | [next] | [standalone]

#111447

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

[toc] | [prev] | [next] | [standalone]

#111459

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.

Ok, back to Dan Cross:: (with help from Scott)

If GuestOS wants to grab and hold onto a lock/mutex for a while
to do some critical section stuff--does GuestOS "care" that HV
can still take an interrupt while GuestOS is doing its CS thing ??
since HV is not going to touch any memory associated with GuestOS.

In effect, I am asking is Disable Interrupt is SW-stack-wide or only
applicable to the current layer of the SW stack ?? One can equally
use SW-stack-wide to mean core-wide.

For example:: GuestOS DIs, and HV takes a page fault from GuestOS;
makes the page resident and accessible, and allows GuestOS to run
from the point of fault. GuestOS "sees" no interrupt and nothing
in GuestOS VAS is touched by HV in servicing the page fault.

Now, sure that lock is held while the page fault is being serviced,
and the ugly head of priority inversion takes hold. But ... I am ni
need of some edumacation here.

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

[toc] | [prev] | [next] | [standalone]

#111460

mitchalsup@aol.com (MitchAlsup1) writes:
>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.
>
>Ok, back to Dan Cross:: (with help from Scott)
>
>If GuestOS wants to grab and hold onto a lock/mutex for a while
>to do some critical section stuff--does GuestOS "care" that HV
>can still take an interrupt while GuestOS is doing its CS thing ??
>since HV is not going to touch any memory associated with GuestOS.

Generally, the Guest should execute "as if" it were running on
Bare Metal.  Consider an intel/amd processor running a bare-metal
operating system that takes an interrupt into SMM mode;  from the
POV of a guest, an HV interrupt is similar to an SMM interrupt.

If the SMM, Secure Monitor or HV modify guest memory in any way,
all bets are off.

>
>In effect, I am asking is Disable Interrupt is SW-stack-wide or only
>applicable to the current layer of the SW stack ?? One can equally
>use SW-stack-wide to mean core-wide.

Current layer of the privilege stack.   If there is a secure monitor
at a more privileged level than the HV, it can take interrupts in a
manner similar to the legacy SMM interupts.  Typically there will
be independent periodic timer interrupts in the Guest OS, the HV, and the
secure monitor.

>
>For example:: GuestOS DIs, and HV takes a page fault from GuestOS;

Note that these will be rare and only if the HV overcommits physical
memory.

>makes the page resident and accessible, and allows GuestOS to run
>from the point of fault. GuestOS "sees" no interrupt and nothing
>in GuestOS VAS is touched by HV in servicing the page fault.

The only way that the guest OS or guest OS application can detect
such an event is if it measures an affected load/store - a covert
channel.  So there may be security considerations.

>
>Now, sure that lock is held while the page fault is being serviced,
>and the ugly head of priority inversion takes hold. But ... I am ni
>need of some edumacation here.

Priority inversion is only applicable within a privilege level/ring.
Interrupts to a higher privilege level cannot be masked by an active interrupt
at a lower priority level.

The higher privilege level must not unilaterally modify guest OS or
application state.

[toc] | [prev] | [next] | [standalone]

#111461

On Tue, 15 Apr 2025 14:02:37 +0000, Scott Lurndal wrote:

> mitchalsup@aol.com (MitchAlsup1) writes:
>>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.
>>
>>Ok, back to Dan Cross:: (with help from Scott)
>>
>>If GuestOS wants to grab and hold onto a lock/mutex for a while
>>to do some critical section stuff--does GuestOS "care" that HV
>>can still take an interrupt while GuestOS is doing its CS thing ??
>>since HV is not going to touch any memory associated with GuestOS.
>
> Generally, the Guest should execute "as if" it were running on
> Bare Metal.  Consider an intel/amd processor running a bare-metal
> operating system that takes an interrupt into SMM mode;  from the
> POV of a guest, an HV interrupt is similar to an SMM interrupt.
>
> If the SMM, Secure Monitor or HV modify guest memory in any way,
> all bets are off.

Yes, but we have previously established HV does its virtualization
without touching GuestOS memory. {Which is why I used page fault as
the example.}

>>
>>In effect, I am asking is Disable Interrupt is SW-stack-wide or only
>>applicable to the current layer of the SW stack ?? One can equally
>>use SW-stack-wide to mean core-wide.
>
> Current layer of the privilege stack.   If there is a secure monitor
> at a more privileged level than the HV, it can take interrupts in a
> manner similar to the legacy SMM interupts.  Typically there will
> be independent periodic timer interrupts in the Guest OS, the HV, and
> the secure monitor.

This agrees with the RISC-V approach where each layer in the stack
has its own Interrupt Enable configuration. {Which is what lead to
my questions}.

However, many architectures have only a single control bit for the
whole core--which is shy I am trying to get a complete understanding
of what is required and what is choice. That there is some control
is (IS) required--how many seems to be choice at this stage.

Would it be unwise of me to speculate that a control at each layer
is more optimal, or that the critical section that is delayed due
to "other stuff needing to be handled" should have taken precedent.

Anyone know of any literature where this was simulate or measured ??

>>
>>For example:: GuestOS DIs, and HV takes a page fault from GuestOS;
>
> Note that these will be rare and only if the HV overcommits physical
> memory.
>
>>makes the page resident and accessible, and allows GuestOS to run
>>from the point of fault. GuestOS "sees" no interrupt and nothing
>>in GuestOS VAS is touched by HV in servicing the page fault.
>
> The only way that the guest OS or guest OS application can detect
> such an event is if it measures an affected load/store - a covert
> channel.  So there may be security considerations.

Damn that high precision clock .....

Which also leads to the question of should a Virtual Machine have
its own virtual time ?? {Or VM and VMM share the concept of virtual
time} ??

>>
>>Now, sure that lock is held while the page fault is being serviced,
>>and the ugly head of priority inversion takes hold. But ... I am ni
>>need of some edumacation here.
>
> Priority inversion is only applicable within a privilege level/ring.
> Interrupts to a higher privilege level cannot be masked by an active
> interrupt at a lower priority level.

So, if core is running HyperVisor at priority 15 and a user interrupt
arrives at a higher priority but directed at GuestOS (instead of HV)
does::
a) HV continue leaving higher priority interrupt waiting.
b) switch back to GuestOS for higher priority interrupt--in such
. a way that when GuestOS returns from interrupt HV takes over
. from whence it left.

This is really a question of what priority means across the entire
SW stack--and real-time versus Linux may have different answers on
this matter.

> The higher privilege level must not unilaterally modify guest OS or
> application state.

Given the almost complete lack of shared address spaces in a manner
where pointers can be passed between, there is almost nothing an HV
can do to a GuestOS VAS unless GuestOS has ask for a HV service via
paravirtualization entry point.

[toc] | [prev] | [next] | [standalone]

#111462

mitchalsup@aol.com (MitchAlsup1) writes:
>On Tue, 15 Apr 2025 14:02:37 +0000, Scott Lurndal wrote:
>


>>
>> Current layer of the privilege stack.   If there is a secure monitor
>> at a more privileged level than the HV, it can take interrupts in a
>> manner similar to the legacy SMM interupts.  Typically there will
>> be independent periodic timer interrupts in the Guest OS, the HV, and
>> the secure monitor.
>
>This agrees with the RISC-V approach where each layer in the stack
>has its own Interrupt Enable configuration. {Which is what lead to
>my questions}.

AArch64 also had interrupt enables at each privilege level.

>
>However, many architectures have only a single control bit for the
>whole core--which is shy I am trying to get a complete understanding
>of what is required and what is choice. That there is some control
>is (IS) required--how many seems to be choice at this stage.

I'm not aware of any architecture that supports virtualization that
doesn't have enables for each privilege level;  either there are
distinct levels in hardware, or the hypervisor needs to handle
all interrupts and inject them into the guest in some fashion.  Best
to have hardware support for all of this rather than the overhead
of the HV handing all interrupts and the consequent context switches.

>Would it be unwise of me to speculate that a control at each layer
>is more optimal, or that the critical section that is delayed due
>to "other stuff needing to be handled" should have taken precedent.

The former is optimal.  Assumning the guest is independent of the
HV, any delay in the critical section (e.g. due to an HV interrupt
being handled) are inconsequential.  The critical section is only
critical to the privilege layer it occurs on.

 <snip>

>
>>
>> The only way that the guest OS or guest OS application can detect
>> such an event is if it measures an affected load/store - a covert
>> channel.  So there may be security considerations.
>
>Damn that high precision clock .....
>
>Which also leads to the question of should a Virtual Machine have
>its own virtual time ?? {Or VM and VMM share the concept of virtual
>time} ??

Generally, yes.    Usually modeled with an offset register in
the HV that gets applied to the guest view of current time.

>
>>>
>>>Now, sure that lock is held while the page fault is being serviced,
>>>and the ugly head of priority inversion takes hold. But ... I am ni
>>>need of some edumacation here.
>>
>> Priority inversion is only applicable within a privilege level/ring.
>> Interrupts to a higher privilege level cannot be masked by an active
>> interrupt at a lower priority level.
>
>So, if core is running HyperVisor at priority 15 and a user interrupt
>arrives at a higher priority but directed at GuestOS (instead of HV)
>does::
>a) HV continue leaving higher priority interrupt waiting.
>b) switch back to GuestOS for higher priority interrupt--in such
>. a way that when GuestOS returns from interrupt HV takes over
>. from whence it left.

ARM, for example, splits the per-core interrupt  priority range into halves
- one half is assigned to the secure monitor and the other is assigned to the
non-secure software running on the core.  Early hypervisors would field all
non-secure interrupts and either handle them itself or inject them into
the guest.    The first ARM64 cores would field all interrupts in the HV
and the int controller had special registers the HV could use to inject interrupts
into the guest.    The overhead was not insignifcant, so they added
a mechanism to allow some interrupts to be directly fielded by the
guest itself - avoiding the round trip through the HV on every interrupt
(called virtual LPIs).

>
>This is really a question of what priority means across the entire
>SW stack--and real-time versus Linux may have different answers on
>this matter.
>
>> The higher privilege level must not unilaterally modify guest OS or
>> application state.
>
>Given the almost complete lack of shared address spaces in a manner
>where pointers can be passed between, there is almost nothing an HV
>can do to a GuestOS VAS unless GuestOS has ask for a HV service via
>paravirtualization entry point.

The HV owns the translation tables for guest to physical address,
it can pretty much do anything it wants with that access[*], including
modifying guest processor and memory state at any time - absent
potential future features such as hardware guest memory encryption
or memory access controls at a level higher than the HV (e.g. the
secure monitor - see AArch64 Realms, for example).

https://developer.arm.com/documentation/den0126/0101/Overview

[*] the hypervisor can easily double map a page in both the guest PAS
    and the HV VAS - a technique common in paravirtualized environments.

[toc] | [prev] | [next] | [standalone]

#111463

On Wed, 16 Apr 2025 14:07:36 +0000, Scott Lurndal wrote:

> mitchalsup@aol.com (MitchAlsup1) writes:
---------snip-----------
>>
>>So, if core is running HyperVisor at priority 15 and a user interrupt
>>arrives at a higher priority but directed at GuestOS (instead of HV)
>>does::
>>a) HV continue leaving higher priority interrupt waiting.
>>b) switch back to GuestOS for higher priority interrupt--in such
>>. a way that when GuestOS returns from interrupt HV takes over
>>. from whence it left.
>
> ARM, for example, splits the per-core interrupt  priority range into
> halves
> - one half is assigned to the secure monitor and the other is assigned
> to the
> non-secure software running on the core.

Thus, my predilection for 64-priority levels (rather than ~8 as
suggested
by another participant) allows for this distribution of priorities
across
layers in the SW stack at the discretion of trustable-SW.

>                                           Early hypervisors would field
> all
> non-secure interrupts and either handle them itself or inject them into
> the guest.    The first ARM64 cores would field all interrupts in the HV
> and the int controller had special registers the HV could use to inject
> interrupts
> into the guest.    The overhead was not insignifcant, so they added
> a mechanism to allow some interrupts to be directly fielded by the
> guest itself - avoiding the round trip through the HV on every interrupt
> (called virtual LPIs).

Given 4 layers in the stack {Secure, Hyper, Super, User} and we have
interrupts targeting {Secure, Hyper, Super}, do we pick up any liability
or do we gain flexibility by being able to target interrupts directly to
{user} ?? (the 4th element).

Roughly: HW maintains 4 copies of state and generally indexes state
with a 2-bit value, and the "structure" of thread-header is identical
between layers; thus, indexing down to {user} falls out for free.

{{But I could be off my rocker...again}}

[toc] | [prev] | [next] | [standalone]

#111464 — Virtualization layers (was: Constant Stack Canaries)

> Given 4 layers in the stack {Secure, Hyper, Super, User} and we have
> interrupts targeting {Secure, Hyper, Super}, do we pick up any liability
> or do we gain flexibility by being able to target interrupts directly to
> {user} ?? (the 4th element).

All these discussions seem to presume a very fixed structure that (I
presume) corresponds to a typical situation in servers nowadays.

But shouldn't the hardware aim for something more flexible to account
for other use cases?

E.g. What if I want to run my own VM as a user?  Or my own HV?
That's likely to be a common desire for people working on the
development and testing of OSes and HVs?


        Stefan

[toc] | [prev] | [next] | [standalone]

#111465 — Re: Virtualization layers

On Wed, 16 Apr 2025 21:48:49 +0000, Stefan Monnier wrote:

>> Given 4 layers in the stack {Secure, Hyper, Super, User} and we have
>> interrupts targeting {Secure, Hyper, Super}, do we pick up any liability
>> or do we gain flexibility by being able to target interrupts directly to
>> {user} ?? (the 4th element).
>
> All these discussions seem to presume a very fixed structure that (I
> presume) corresponds to a typical situation in servers nowadays.
>
> But shouldn't the hardware aim for something more flexible to account
> for other use cases?

The goal is that::
The two layers in the middle can be managed as an accordion; supporting
any number of HVs and GuestOSs between Secure and User.

> E.g. What if I want to run my own VM as a user?  Or my own HV?
> That's likely to be a common desire for people working on the
> development and testing of OSes and HVs?

Use the accordion

>
>         Stefan

[toc] | [prev] | [next] | [standalone]

#111468 — Re: Virtualization layers (was: Constant Stack Canaries)

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> Given 4 layers in the stack {Secure, Hyper, Super, User} and we have
>> interrupts targeting {Secure, Hyper, Super}, do we pick up any liability
>> or do we gain flexibility by being able to target interrupts directly to
>> {user} ?? (the 4th element).
>
>All these discussions seem to presume a very fixed structure that (I
>presume) corresponds to a typical situation in servers nowadays.
>
>But shouldn't the hardware aim for something more flexible to account
>for other use cases?
>
>E.g. What if I want to run my own VM as a user?  Or my own HV?
>That's likely to be a common desire for people working on the
>development and testing of OSes and HVs?

ARM has hardware support for nested hypervisors. It can be tricky.

[toc] | [prev] | [next] | [standalone]

#111466

On 4/16/2025 2:13 PM, MitchAlsup1 wrote:
> On Wed, 16 Apr 2025 14:07:36 +0000, Scott Lurndal wrote:
> 
>> mitchalsup@aol.com (MitchAlsup1) writes:
> ---------snip-----------
>>>
>>> So, if core is running HyperVisor at priority 15 and a user interrupt
>>> arrives at a higher priority but directed at GuestOS (instead of HV)
>>> does::
>>> a) HV continue leaving higher priority interrupt waiting.
>>> b) switch back to GuestOS for higher priority interrupt--in such
>>> . a way that when GuestOS returns from interrupt HV takes over
>>> . from whence it left.
>>
>> ARM, for example, splits the per-core interrupt  priority range into
>> halves
>> - one half is assigned to the secure monitor and the other is assigned
>> to the
>> non-secure software running on the core.
> 
> Thus, my predilection for 64-priority levels (rather than ~8 as
> suggested
> by another participant) allows for this distribution of priorities
> across
> layers in the SW stack at the discretion of trustable-SW.
> 
>>                                           Early hypervisors would field
>> all
>> non-secure interrupts and either handle them itself or inject them into
>> the guest.    The first ARM64 cores would field all interrupts in the HV
>> and the int controller had special registers the HV could use to inject
>> interrupts
>> into the guest.    The overhead was not insignifcant, so they added
>> a mechanism to allow some interrupts to be directly fielded by the
>> guest itself - avoiding the round trip through the HV on every interrupt
>> (called virtual LPIs).
> 
> Given 4 layers in the stack {Secure, Hyper, Super, User} and we have
> interrupts targeting {Secure, Hyper, Super}, do we pick up any liability
> or do we gain flexibility by being able to target interrupts directly to
> {user} ?? (the 4th element).

I think you could gain a tiny amount of efficiency if the OS (super) 
allowed the user to set up handle certain classes of exceptions, e.g. 
divide faults) itself rather than having to go through the super.


-- 
  - Stephen Fuld
(e-mail address disguised to prevent spam)

[toc] | [prev] | [next] | [standalone]

#111469

Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:
>On 4/16/2025 2:13 PM, MitchAlsup1 wrote:
>> On Wed, 16 Apr 2025 14:07:36 +0000, Scott Lurndal wrote:
>> 
>>> mitchalsup@aol.com (MitchAlsup1) writes:
>> ---------snip-----------
>>>>
>>>> So, if core is running HyperVisor at priority 15 and a user interrupt
>>>> arrives at a higher priority but directed at GuestOS (instead of HV)
>>>> does::
>>>> a) HV continue leaving higher priority interrupt waiting.
>>>> b) switch back to GuestOS for higher priority interrupt--in such
>>>> . a way that when GuestOS returns from interrupt HV takes over
>>>> . from whence it left.
>>>
>>> ARM, for example, splits the per-core interrupt  priority range into
>>> halves
>>> - one half is assigned to the secure monitor and the other is assigned
>>> to the
>>> non-secure software running on the core.
>> 
>> Thus, my predilection for 64-priority levels (rather than ~8 as
>> suggested
>> by another participant) allows for this distribution of priorities
>> across
>> layers in the SW stack at the discretion of trustable-SW.
>> 
>>>                                           Early hypervisors would field
>>> all
>>> non-secure interrupts and either handle them itself or inject them into
>>> the guest.    The first ARM64 cores would field all interrupts in the HV
>>> and the int controller had special registers the HV could use to inject
>>> interrupts
>>> into the guest.    The overhead was not insignifcant, so they added
>>> a mechanism to allow some interrupts to be directly fielded by the
>>> guest itself - avoiding the round trip through the HV on every interrupt
>>> (called virtual LPIs).
>> 
>> Given 4 layers in the stack {Secure, Hyper, Super, User} and we have
>> interrupts targeting {Secure, Hyper, Super}, do we pick up any liability
>> or do we gain flexibility by being able to target interrupts directly to
>> {user} ?? (the 4th element).
>
>I think you could gain a tiny amount of efficiency if the OS (super) 
>allowed the user to set up handle certain classes of exceptions, e.g. 
>divide faults) itself rather than having to go through the super.

Think carefully about the security implications of user-mode interrupt
delivery.  Particuarly with respect to potential impacts on other
processes running on the system, and to overall system functionality.

Handling interrupts requires direct access to the hardware from
user-mode.

Hardware access is normally done in the context of a 'sandboxed'
PCI Express SRIOV function which the application can access directly;
the hardware guarantees that the user process cannot adversley
affect the hardware or other guests using other virtual functions.

However, the interrupt controller itself (e.g. the mechanism used
to acknowledge the interrupt to the interrupt controller after it
has been serviced - e.g. the LAPIC) isn't virtualized, and direct
access to that shouldn't be available to user-mode for fairly obvious
reasons.

That's why DPDK/ODP  require the OS to handle interrupts and notify
the application via standard OS notification mechanisms even
when using SR-IOV capable hardware for the actual packet handling.

[toc] | [prev] | [next] | [standalone]

#111470 — Re: virtualization, Constant Stack Canaries

According to Scott Lurndal <slp53@pacbell.net>:
>>I think you could gain a tiny amount of efficiency if the OS (super) 
>>allowed the user to set up handle certain classes of exceptions, e.g. 
>>divide faults) itself rather than having to go through the super.
>
>Think carefully about the security implications of user-mode interrupt
>delivery.  Particuarly with respect to potential impacts on other
>processes running on the system, and to overall system functionality.
>
>Handling interrupts requires direct access to the hardware from
>user-mode.

I think he was talking about exceptions, not interrupts.  I don't see much
danger in reflecting divide faults and supervisor calls directly back
to the virtual machine.  I gather that IBM's virtualization microcode has
done that for decades.

External interrupts are indeed a lot harder unless you know a whole lot
about the thing that's interrupting.
-- 
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

[toc] | [prev] | [next] | [standalone]

#111471 — Re: virtualization, Constant Stack Canaries

> External interrupts are indeed a lot harder unless you know a whole lot
> about the thing that's interrupting.

Not only the thing that's interrupting but also the thing
it's interrupting.  Maybe it's easier for My 66000 where I understand
that the hardware has a notion of threads/processes so it may be able to
know how to deliver the interrupt to the appropriate thread/process.


        Stefan

[toc] | [prev] | [next] | [standalone]

#111474 — Re: virtualization, Constant Stack Canaries

On 4/16/2025 6:04 PM, John Levine wrote:
> According to Scott Lurndal <slp53@pacbell.net>:
>>> I think you could gain a tiny amount of efficiency if the OS (super)
>>> allowed the user to set up handle certain classes of exceptions, e.g.
>>> divide faults) itself rather than having to go through the super.
>>
>> Think carefully about the security implications of user-mode interrupt
>> delivery.  Particuarly with respect to potential impacts on other
>> processes running on the system, and to overall system functionality.
>>
>> Handling interrupts requires direct access to the hardware from
>> user-mode.
> 
> I think he was talking about exceptions, not interrupts. 

Right.  Thanks John.  I was careful to say exceptions, not interrupts.


> I don't see much
> danger in reflecting divide faults and supervisor calls directly back
> to the virtual machine.  I gather that IBM's virtualization microcode has
> done that for decades.

I was suggesting that for things like divide fault, it could go directly 
back to the user, assuming the user had set up a place to handle them.

> 
> External interrupts are indeed a lot harder unless you know a whole lot
> about the thing that's interrupting.

Yup.

-- 
  - Stephen Fuld
(e-mail address disguised to prevent spam)

[toc] | [prev] | [next] | [standalone]

#111475 — Re: virtualization, Constant Stack Canaries

John Levine <johnl@taugh.com> writes:
>According to Scott Lurndal <slp53@pacbell.net>:
>>>I think you could gain a tiny amount of efficiency if the OS (super) 
>>>allowed the user to set up handle certain classes of exceptions, e.g. 
>>>divide faults) itself rather than having to go through the super.
>>
>>Think carefully about the security implications of user-mode interrupt
>>delivery.  Particuarly with respect to potential impacts on other
>>processes running on the system, and to overall system functionality.
>>
>>Handling interrupts requires direct access to the hardware from
>>user-mode.
>
>I think he was talking about exceptions, not interrupts.  I don't see much
>danger in reflecting divide faults and supervisor calls directly back
>to the virtual machine.  I gather that IBM's virtualization microcode has
>done that for decades.

All the current processors (intel, AMD, ARM, MIPS) that have hardware
virtualization support handle faults in the context in which they
arise.  e.g. a divide fault will be handled directly by the guest
OS without any hypervisor intervention.  The single standard exception
is user mode, where the faults are handled by the Guest/Bare-metal
OS.

>
>External interrupts are indeed a lot harder unless you know a whole lot
>about the thing that's interrupting.

Indeed, although it's not so much about the 'thing that's interrupting'
as it is about the interrupt infrastructure (i.e. interrupt controller)
itself.

[toc] | [prev] | [next] | [standalone]

#111478 — Re: virtualization, Constant Stack Canaries

On Thu, 17 Apr 2025 1:04:10 +0000, John Levine wrote:

> According to Scott Lurndal <slp53@pacbell.net>:
>>>I think you could gain a tiny amount of efficiency if the OS (super)
>>>allowed the user to set up handle certain classes of exceptions, e.g.
>>>divide faults) itself rather than having to go through the super.
>>
>>Think carefully about the security implications of user-mode interrupt
>>delivery.  Particuarly with respect to potential impacts on other
>>processes running on the system, and to overall system functionality.
>>
>>Handling interrupts requires direct access to the hardware from
>>user-mode.
>
> I think he was talking about exceptions, not interrupts.  I don't see
> much danger in reflecting divide faults and supervisor calls directly
> back
> to the virtual machine.  I gather that IBM's virtualization microcode
> has done that for decades.

I used (I think) the word interrupted as in "the thread currently in
control
has its instruction stream interrupted" which could stand in for
interrupts
or exceptions or faults; to see how the conversation develops.

It seems to me that to "take" and interrupt at user layer in SW-stack,
that the 3-upper layers have to be in the same state as when that User
thread is in control of a core. But, It also seems to me that to "take"
an interrupt into Super, the 2 higher layers of SW-stack also have to
be as they were when that Super thread has control. You don't want
HV[j].GuestOS[k] to take an interrupt when Hyper != HV[j] && Super !=
GuestOS[k] -- because the various translation tables are not properly
available to perform the nested MMU VAS->UAS translation.

In effect, the SW-stack becomes some kind of "closure" where control
can be transferred asynchronously. Enough information is passed (as
arguments) across this boundary that efficient dispatch to the proper
ISR is but a few instructions (3 typically in My 66000).

> External interrupts are indeed a lot harder unless you know a whole lot
> about the thing that's interrupting.

[toc] | [prev] | [next] | [standalone]

#111480 — Re: virtualization, Constant Stack Canaries

mitchalsup@aol.com (MitchAlsup1) writes:
>On Thu, 17 Apr 2025 1:04:10 +0000, John Levine wrote:
>
>> According to Scott Lurndal <slp53@pacbell.net>:
>>>>I think you could gain a tiny amount of efficiency if the OS (super)
>>>>allowed the user to set up handle certain classes of exceptions, e.g.
>>>>divide faults) itself rather than having to go through the super.
>>>
>>>Think carefully about the security implications of user-mode interrupt
>>>delivery.  Particuarly with respect to potential impacts on other
>>>processes running on the system, and to overall system functionality.
>>>
>>>Handling interrupts requires direct access to the hardware from
>>>user-mode.
>>
>> I think he was talking about exceptions, not interrupts.  I don't see
>> much danger in reflecting divide faults and supervisor calls directly
>> back
>> to the virtual machine.  I gather that IBM's virtualization microcode
>> has done that for decades.
>
>I used (I think) the word interrupted as in "the thread currently in
>control
>has its instruction stream interrupted" which could stand in for
>interrupts
>or exceptions or faults; to see how the conversation develops.

In ARM64, an interrupt is just a maskable asynchronous exception.

>
>It seems to me that to "take" and interrupt at user layer in SW-stack,
>that the 3-upper layers have to be in the same state as when that User
>thread is in control of a core. But, It also seems to me that to "take"
>an interrupt into Super, the 2 higher layers of SW-stack also have to
>be as they were when that Super thread has control. You don't want
>HV[j].GuestOS[k] to take an interrupt when Hyper != HV[j] && Super !=
>GuestOS[k] -- because the various translation tables are not properly
>available to perform the nested MMU VAS->UAS translation.

Note that while any one layer is executing _on a core/hardware thread_,
the other layers aren't running on that core, by definition.  However, there is
no synchronization with other cores, so other cores in the same system
may be executing in any one or all of the privilege levels/security layers
while a given core is taking an exception (synchronous or asynchronous).

[toc] | [prev] | [next] | [standalone]

#111481 — Re: virtualization, Constant Stack Canaries

On Thu, 17 Apr 2025 20:10:11 +0000, Scott Lurndal wrote:

> mitchalsup@aol.com (MitchAlsup1) writes:
>>On Thu, 17 Apr 2025 1:04:10 +0000, John Levine wrote:
>>
>>> According to Scott Lurndal <slp53@pacbell.net>:
>>>>>I think you could gain a tiny amount of efficiency if the OS (super)
>>>>>allowed the user to set up handle certain classes of exceptions, e.g.
>>>>>divide faults) itself rather than having to go through the super.
>>>>
>>>>Think carefully about the security implications of user-mode interrupt
>>>>delivery.  Particuarly with respect to potential impacts on other
>>>>processes running on the system, and to overall system functionality.
>>>>
>>>>Handling interrupts requires direct access to the hardware from
>>>>user-mode.
>>>
>>> I think he was talking about exceptions, not interrupts.  I don't see
>>> much danger in reflecting divide faults and supervisor calls directly
>>> back
>>> to the virtual machine.  I gather that IBM's virtualization microcode
>>> has done that for decades.
>>
>>I used (I think) the word interrupted as in "the thread currently in
>>control
>>has its instruction stream interrupted" which could stand in for
>>interrupts
>>or exceptions or faults; to see how the conversation develops.
>
> In ARM64, an interrupt is just a maskable asynchronous exception.

My 66000 defines:
a) exception: something wrong in the attempt to execute an instruction
b) interrupt: asynchronous events not related to instruction execution
c) trap ... : request for service to next higher privilege layer
d) check .. : something that should (almost) never happen

Unlike many RISC architectures, My 66000 has arithmetic exceptions
{Operand Domain, Result Range, privilege, 5-IEEE exceptions} along
with typical {GuestOS page fault, Hypervisor page fault} everybody
has. Much more IBM 360-like than MIPS-like.

Exceptions are then categorized as repairable-faults or terminations.
SW determines if arithmetic faults are recognized and what to do
with the exception if one is raised and recognized {terminate, repair,
complete}. Page faults operate under "repair" state is repaired such
that re-execution of the instruction should now succeed. Complete is
for situations where a HW cannot deliver "an acceptable" result, but
SW can. Here, SW "completes" the work and returns following the causing
instruction.

Checks are things like
1) unrepairable ECC failure
2) special privilege violations
3) hardware failures
4) power or reset events

Which either log the event, attempt repair, or panic the VMM.

Checks are simply exceptions that deliver control to {secure}
instead of {next higher privilege} and checks are not maskable.
{I may come to regret this non-maskable part ...}

>>
>>It seems to me that to "take" and interrupt at user layer in SW-stack,
>>that the 3-upper layers have to be in the same state as when that User
>>thread is in control of a core. But, It also seems to me that to "take"
>>an interrupt into Super, the 2 higher layers of SW-stack also have to
>>be as they were when that Super thread has control. You don't want
>>HV[j].GuestOS[k] to take an interrupt when Hyper != HV[j] && Super !=
>>GuestOS[k] -- because the various translation tables are not properly
>>available to perform the nested MMU VAS->UAS translation.
>
> Note that while any one layer is executing _on a core/hardware thread_,
> the other layers aren't running on that core,

Not "running" but those layer's CRs are still supporting lower privilege
layers that ARE running on that core. Mostly in the nested Root pointer
and ASID categories, sometimes in the interrupt-table category.

>                                               by definition.  However,
> there is
> no synchronization with other cores, so other cores in the same system
> may be executing in any one or all of the privilege levels/security
> layers
> while a given core is taking an exception (synchronous or asynchronous).

Yes, obviously. Any core can be operating at any priority any privilege
any layer unbeknownst to any other core; until and unless SW tries to
synchronize with said other core to find out.

[toc] | [prev] | [next] | [standalone]

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

Back to top | Article view | comp.arch

csiph-web