Re: [Xen-devel] [PATCH v3 2/2] xsm: hide detailed Xen version from unprivileged guests

[Jan Beulich <jbeulich@xxxxxxxx>]

On 22.01.2020 13:05, Julien Grall wrote:
> Hi George,
> 
> On 22/01/2020 10:57, George Dunlap wrote:
>> On 1/22/20 10:14 AM, Julien Grall wrote:
>>>
>>>
>>> On 22/01/2020 10:01, Sergey Dyasli wrote:
>>>> On 20/01/2020 10:01, Jan Beulich wrote:
>>>>> On 17.01.2020 17:44, Sergey Dyasli wrote:
>>>>>> v2 --> v3:
>>>>>> - Remove hvmloader filtering
>>>>>
>>>>> Why? Seeing the prior discussion, how about adding XENVER_denied to
>>>>> return the "denied" string, allowing components which want to filter
>>>>> to know exactly what to look for? And then re-add the filtering you
>>>>> had? (The help text of the config option should then perhaps be
>>>>> extended to make very clear that the chosen string should not match
>>>>> anything that could potentially be returned by any of the XENVER_
>>>>> sub-ops.)
>>>>
>>>> I had the following reasoning:
>>>>
>>>> 1. Most real-world users would set CONFIG_XSM_DENIED_STRING="" anyway.
>>>>
>>>> 2. Filtering in DMI tables is not a complete solution, since denied
>>>> string leaks elsewhere through the hypercall (PV guests, sysfs, driver
>>>> logs) as Andrew has pointed out in the previous discussion.
>>>>
>>>> On the other hand, SMBios filtering slightly improves the situation for
>>>> HVM domains, so I can return it if maintainers find it worthy.
>>>
>>> While I am not a maintainer of this code, my concern is you impose the
>>> conversion from "denied" to "" to all the users (include those who wants
>>> to keep "denied").
>>>
>>> If you were doing any filtering in hvmloader, then it would be best if
>>> this is configurable. But this is a bit pointless if you already allow
>>> the user to configure the string at the hypervisor level :).
>>
>> So there are two things we're concerned about:
>> - Some people don't want to scare users with a "<denied>" string
>> - Some people don't want to "silently fail" with a "" string
>>
>> The fact is, in *both cases*, this is a UI problem.  EVERY caller of
>> this interface should figure out independently what a graceful way of
>> handling failure is for their target UI.  Any caller who does not think
>> carefully about what to do in the failure case is buggy -- which
>> includes every single caller today.  The CONFIG_XSM_DENIED_STRING is a
>> gross hack fallback for buggy UIs.
> 
> I agree that the two cases you explained are UI problems. However, I can 
> see other use for the Kconfig option (with some tweaks).
> 
> At AWS, consistency accross two stable versions is very important. So 
> most of the version strings exposed to the guest are fixed. Therefore a 
> guest can be migrated seemlessly between two different versions without 
> seen any change that may break it.

A guest aware of being run on a hypervisor would also be aware
that it may be migrated, and hence that the version of the
underlying hypervisor may change (if it cares about versions
in the first place). A guest unaware of being run on a
hypervisor wouldn't care about version and alike strings at all.
Nevertheless I'm sure you play this game for a (real world)
reason, e.g. people making wrong assumptions. But is this
something you really think the upstream hypervisor should be
made care about?

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel