Re: [RFC PATCH] xen/arm: Add emulation of Debug Data Transfer Registers

[Bertrand Marquis <Bertrand.Marquis@xxxxxxx>]

Hi All,

Sorry for coming back late on this thread.

> On 7 Dec 2023, at 22:41, Stefano Stabellini <sstabellini@xxxxxxxxxx> wrote:
> 
> On Thu, 7 Dec 2023, Julien Grall wrote:
>> Hi Stefano,
>> 
>> On 05/12/2023 23:21, Stefano Stabellini wrote:
>>> On Tue, 5 Dec 2023, Julien Grall wrote:
>>>> I agree that crashing a guest is bad, but is lying to the domain really
>>>> better? The consequence here is not that bad and hopefully it would be
>>>> fairly
>>>> easy to find. But this is not always the case. So I definitely would place
>>>> a
>>>> half-backed emulation more severe than a guest crash.
>>> 
>>> 
>>> I see where Julien is coming from, but I would go with option two:
>>> "emulate DCC the same way as KVM". That's because I don't think we can
>>> get away with crashing the guest in all cases. Although the issue came
>>> up with a Linux guest, it could have been triggered by a proprietary
>>> operating system that we cannot change, and I think Xen should support
>>> running unmodified operating systems.
>>> 
>>> If we go with a "half-backed emulation" solution, as Julien wrote, then
>>> it is better to be more similar to other hypervisors, that's why I chose
>>> option two instead of option three.
>>> 
>>> But at the same time I recognize the validity of Julien's words and it
>>> makes me wonder if we should have a KCONFIG option or command line
>>> option to switch the Xen behavior. We could use it to gate all the
>>> "half-backed emulation" we do for compatibility.  Something like:
>>> 
>>> config PARTIAL_EMULATION
>>>     bool "Partial Emulation"
>>>     ---help---
>>>           Enables partial, not spec compliant, emulation of certain
>>> register
>>>     interfaces (e.g DCC UART) for guest compatibility. If you disable
>>>     this option, Xen will crash the guest if the guest tries to access
>>>     interfaces not fully emulated or virtualized.
>>> 
>>>     If you enable this option, the guest might misbehave due to non-spec
>>>     compliant emulation done by Xen.
>> 
>> As I wrote to Ayan on Matrix today, I am not in favor of the emulation. Yet, 
>> I
>> am not going to oppose (as in Nack it) if the other maintainers agree with 
>> it.
> 
> Thanks for being flexible
> 
> 
>> The KConfig would be nice, the question is whether we want to (security)
>> support such configuration? E.g. could this potentially introduce a security
>> issue in the guest?
> 
> The important question is whether it could introduce a security issue in
> Xen. If we think it wouldn't increase the attack surface significantly
> then I would security support it otherwise not.
> 
> 
>> Regarding the  emulation itself, I actually prefer 3 because at least the
>> Linux drivers will be able to bail out rather than trying to use them.
> 
> I don't have a strong opinion between 2 and 3

Here is my view on it:
- providing a wrong emulation to please guests is not wrong as it might end
up hidding something that will be hard to debug so on that point I agree with
Julien.
- choosing a solution which might just crash a guest without any other solution
than recompiling or modifying xen is not something acceptable if we want Xen
to thrive.

So i would suggest the following solution:
- have a Kconfig to surround this code so that "correct" guests can disable it.
- have a command line option to activate this behavior and turn it off by 
default.
One encountering the problem will have to explicitly set a command line 
parameter
so cannot do this without knowing.
- activate the Kconfig option by default and security support it as it is only 
active if
a command line parameter is passed.

The Kconfig parameter should be more generic so that this could apply to a 
bunch of
registers we would emulate with RAZ/WI so I am happy with that proposal if we 
say
that this must be activated through a command line option passed to Xen at boot.

Regards
Bertrand