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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 22.01.2020 11: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.

Well, that's Andrew's thinking. To me, getting back "<denied>" from
the hypercall is not a leaking of this string, but the intended
output. I continue to think that getting back a blank string there
is confusing, as it is far more likely to be mistaken to be actually
blank than it is for "<denied>" to be mistaken for actual data.
Where such a string wants filtering is to be determined for every
consumer of this interface separately; as said before, this is a UI
function, not something to be catered for in the hypervisor.

Jan

> On the other hand, SMBios filtering slightly improves the situation for
> HVM domains, so I can return it if maintainers find it worthy.
> 
> --
> Thanks,
> Sergey
> 


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