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

[Julien Grall <julien@xxxxxxx>]

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.
Regarding CONFIG_XSM_DENIED_STRING, I think this is a good step as it 
allows the vendor to configure it.
Cheers,

--
Julien Grall

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