On 1/23/20 2:52 PM, Julien Grall wrote: > Hi, > > On 23/01/2020 14:45, George Dunlap wrote: >> On 1/23/20 2:42 PM, Julien Grall wrote: >>> Hi, >>> >>> On 23/01/2020 11:32, Sergey Dyasli wrote: >>>> 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. >>> >>> I am not going to comment on the user experience because this is up to >>> another bikeshedding. The question is which string will you use? Why an >>> empty string over something different? >>> >>> However, if an admin has control over the "deny" string, why would he >>> ever want to filter it in hvmloader? Why can't he just replace the one >>> in Kconfig? >> >> Most admins don't compile their own version of Xen... > > Those admins are also unlikely going to build there own hvmloader, right? > > Therefore, they will have to accept whatever string is reported by > HVMLoader (or Xen). As you already allow Xen to configure it, why would > that be a problem to change the one in Kconfig? Why do you need to fix > it up in hvmloader as well?
Right, the idea was perhaps as upstream, we should modify hvmloader to *always* replace "<denied>" with "". (Or potentially with a more benign string, like "hypervisor build unknown".) -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
