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

[Julien Grall <julien@xxxxxxx>]

On 22/01/2020 12:32, Jan Beulich wrote:
> On 22.01.2020 13:05, Julien Grall wrote:
> > 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.
> A guest aware of being run on a hypervisor would also be aware
> that it may be migrated, and hence that the version of the
> underlying hypervisor may change (if it cares about versions
> in the first place).
If you use upstream-as-is yes. But with the on-going discussion 
regarding live udpate and guest transparent migration, a guest would 
seemlessly move between Xen versions without even been aware.
> A guest unaware of being run on a
> hypervisor wouldn't care about version and alike strings at all.
> Nevertheless I'm sure you play this game for a (real world)
> reason, e.g. people making wrong assumptions. But is this
> something you really think the upstream hypervisor should be
> made care about?
I agree that upstream does not necessarily needs it today. But this is 
an example on how configurable version strings could be useful by 
downstream users.
Cheers,

--
Julien Grall

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