Re: [XEN v5 1/3] xen/arm: Introduce CONFIG_PARTIAL_EMULATION and "partial-emulation" cmd option

[Jan Beulich <jbeulich@xxxxxxxx>]

On 20.02.2024 16:22, Ayan Kumar Halder wrote:
> On 20/02/2024 12:33, Jan Beulich wrote:
>> On 20.02.2024 13:17, Ayan Kumar Halder wrote:
>>> --- a/SUPPORT.md
>>> +++ b/SUPPORT.md
>>> @@ -101,6 +101,18 @@ Extension to the GICv3 interrupt controller to support 
>>> MSI.
>>>   
>>>       Status: Experimental
>>>   
>>> +### ARM/Partial Emulation
>>> +
>>> +Enable partial emulation of registers, otherwise considered unimplemented,
>>> +that would normally trigger a fault injection.
>>> +
>>> +    Status: Supported, with caveats
>>> +
>>> +Bugs allowing the userspace to attack the guest OS will not be considered
>>> +security vulnerabilities.
>>> +
>>> +Bugs that could compromise Xen will be considered security vulnerabilities.
>> ... the odd statement regarding in-guest vulnerabilities that might be
>> introduced. I see only two ways of treating this as supported: Either
>> you simply refuse emulation when the access is from user space,
> 
> I am wondering how do we enforce that.
> 
> Let me try to understand this with the current implementation of partial 
> emulation for system registers.
> 
> 1. DBGDTRTX_EL0 :- I understand that EL0 access to this register will 
> cause a trap to EL2. The reason being MDCR_EL2.TDA == 1.
> 
> In that case, if we refuse emulation then an undef exception is injected 
> to the guest (this is the behavior as of today even without this patch).
> 
> So, are you saying that the undef exception is to be injected to the 
> user space process. This may be possible for Arm64 guests 
> (inject_undef64_exception() needs to be changed).

No, injection is always to the guest, not to a specific entity within the
guest. That ought to be the same on bare hardware: An exception when
raised has an architecturally defined entry point for handling. That'll
typically be kernel code. The handler then figures out whether the source
of the exception was in user or kernel mode. For user mode code, the
kernel may or may not try to handle the exception and then continue the
user mode process. If it can't or doesn't want to handle it, it'll raise
(in UNIX terms) a signal to the process. That signal, in turn, may or may
not be fatal to the process. But such an exception from user mode should
never be fatal to the guest as a whole.

> However for Arm32 guests, this may not be possible as the mode changes 
> to PSR_MODE_UND.

I'm afraid my Arm foo isn't good enough to understand this. On the surface
it looks to violate above outlined principle.

> Let me know if I understood you correctly.
> 
>> or you
>> support that mode of emulation as much as that of kernel space accesses.
> 
> Do you mean we support partial emulation only for traps from EL1 mode ?

Possibly.

Jan