On 22/01/2020 11:25, Julien Grall wrote:
>
>
> On 22/01/2020 11:19, Sergey Dyasli wrote:
>> On 22/01/2020 10:14, 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").
>>
>> This is not what's happening here: the default is still "<denied>" (as
>> per patch 1); but patch 2 makes XENVER_extraversion, XENVER_compile_info
>> and XENVER_changeset to return "<denied>" instead of the real values
>> which causes the UI / logs issues.
>
> I was referring the SMBios filtering... I don't think doing a blank filtering 
> is the right thing to do in the hvmloader for the reason explained above.

Apologies for misunderstanding the context. But I disagree about
hvmloader. Returning "denied" from xen_version hypercall to guests is
one thing, but hvmloader and SMBios tables are parts of the hypervisor
and putting "denied" there is simply a terrible user experience.

>
> Regarding CONFIG_XSM_DENIED_STRING, I think this is a good step as it allows 
> the vendor to configure it.

--
Thanks,
Sergey

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

Reply via email to