Re: [Xen-devel] XSM in osstest, grub config, outstanding patch

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Tue, May 29, 2018 at 12:29:36AM -0500, Doug Goldstein wrote:
> On 5/17/18 10:09 AM, Ian Jackson wrote:
> > Hi, I'm emailing you because I know you have an interest in XSM
> > (and therefore in its testing in osstest).
> > 
> > osstest manages the booting of its test hosts using the
> > distro-supplied bootloader arrangements for its dom0s.  For Debian
> > that is update-grub.  Currently, osstest has a hacked-up local copy of
> > the Xen bit of update-grub, /etc/grub.d/20_linux_xen.  This is in
> > serious danger of diverging from upstream, which is quite bad.
> > 
> > I am intending to drop this file from osstest installs of Debian dom0s
> > after stretch (ie, for Debian buster).  Currently all the deviations
> > from upstream we have been carrying are fixed, except for one
> > XSM-related change.
> > 
> > That change is in the one described in upstream bugtracker here:
> >   https://savannah.gnu.org/bugs/?43420
> > According to the osstest commit message for f12512e44919, this is not
> > quite the same version as is being used by osstest.
> > 
> > This upstream bug is blocked because of unanswered questions about the
> > naming and discovery of policy files.  According to Wei, we don't have
> > a good story about how a user-supplied policy file ought to supplant
> > the one which comes from the Xen build system.
> > 
> > Anyway, without this change, when osstest tries to set up XSM on
> > Debian buster it will not find a bootloader entry with the right
> > policy file.  It will then fail that test.
> > 
> > To avoid this in the most expedient way, it would be good to get a
> > version of this fix into grub upstream before then.
> > 
> > Failing that, as I would be reluctant to continue to carry an
> > ever-diverging piece of grub configuration, I think it would be
> > necessary for there to at least be an upstream bug report with a ready
> > (or nearly-ready) patch; in which case I could provide osstest with a
> > copy of buster's 20_linux_xen file with that patch applied.
> > 
> > In any case, we will want something close to a ready-to-apply patch in
> > the upstream bugtracker.
> > 
> > I am emailing you this now because I have just discovered it.  Happily
> > this will give people plenty of time to debate the policy file naming
> > issue.
> > 
> > Thanks,
> > Ian.
> > 
> 
> So I believe the path forward here was that we'd bake the "default" XSM
> policy into Xen and the user could then override it by supplying one
> with the current name. Ultimately the current Xen build system really
> has no business installing this file. At Star Lab we had our policy in a
> separate repo (in fact we had multiple policies as different packages
> for different objectives). Last I looked OpenXT has their policy in an
> external repo and packages it up separately from Xen. Marek can probably
> answer as to how Qubes does it.
> 
> So the answer to me is no change has to happen to Grub but Xen should
> change to just do the right thing and stop installing that file.
> 

Even if Xen doesn't generate or install its own file, you will still
need to generate a grub entry somehow. How is that done in these
projects?

Wei.

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