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

[Julien Grall <julien@xxxxxxx>]

Hi George,

On 22/01/2020 10:57, George Dunlap wrote:
> On 1/22/20 10:14 AM, 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").
> >
> > If you were doing any filtering in hvmloader, then it would be best if
> > this is configurable. But this is a bit pointless if you already allow
> > the user to configure the string at the hypervisor level :).
> So there are two things we're concerned about:
> - Some people don't want to scare users with a "<denied>" string
> - Some people don't want to "silently fail" with a "" string
>
> The fact is, in *both cases*, this is a UI problem.  EVERY caller of
> this interface should figure out independently what a graceful way of
> handling failure is for their target UI.  Any caller who does not think
> carefully about what to do in the failure case is buggy -- which
> includes every single caller today.  The CONFIG_XSM_DENIED_STRING is a
> gross hack fallback for buggy UIs.
I agree that the two cases you explained are UI problems. However, I can 
see other use for the Kconfig option (with some tweaks).
At AWS, consistency accross two stable versions is very important. So 
most of the version strings exposed to the guest are fixed. Therefore a 
guest can be migrated seemlessly between two different versions without 
seen any change that may break it.
You could imagine using XSM to know whether you want to expose the guest 
the real or fixed version strings. Put it that way, this sounds less a 
gross hack over "<denied>".
The use case described would require multiple Kconfig options though.

> Now, I don't like to tell other people to do work, and I certainly don't
> plan on fixing hvmloader at the moment, because it's low-priority for
> me.  But I do think that having hvmloader detect failure and explicitly
> make a sensible decision is the right thing to do, regardless of the
> availability of CONFIG_XSM_DENIED_STRING to work around buggy callers.
The lengthy discussion about returning "<denied>" shows that we 
(XenProject community) are not in position to decide what is the
sensible value here (even for filtering).

By allowing a vendor to configure the string in the hypervisor, you 
remove that decision from us.
Cheers,

--
Julien Grall

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