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

[Julien Grall <julien@xxxxxxx>]

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?
Cheers,

--
Julien Grall

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