Xen XSM/FLASK policy, grub defaults, etc.

Xen XSM/FLASK policy, grub defaults, etc.

[Ian Jackson]

The Xen tools build system builds a FLASK policy by default.  It does
this even if the hypervisor build for XSM is disabled.

I recently sent patches upstream to grub to support XSM in
update-grub.  update-grub is the program which examines your /boot and
generates appropriate bootloader entries.  My merge request
  https://salsa.debian.org/grub-team/grub/-/merge_requests/18
finds XSM policy files, and when theya are found, generates "XSM
enabled" bootloader entries. [1]

The result of these two things together is that a default build of
grub will result in these "XSM enabled" bootloader entries.  In
practice I think these entries will boot because everything ignores
the additional XSM policy file (!) and Xen ignores the
"flask=enforcing" option (!!)

This is not particularly good.  Offering people an "XSM enabled"
option which does nothing is poor because it might think they have the
extra security but actually significantly more steps are needed.  But
there doesn't appear to be any way for update-grub to tell whether a
particular hypervisor does support XSM or not.

I think the following changes would be good:

1. Xen should reject "flask=enforcing" if it is built without FLASK
support, rather than ignoring it.  This will ensure users are not
misled by these boot options since they will be broken.

2. Xen should disable the XSM policy build when FLASK is disabled.
This is unfortunately not so simple because the XSM policy build is a
tools option and FLASK is a Xen option and the configuration systems
are disjoint.  But at the very least a default build, which has no XSM
support, should not build an XSM policy file either.

3. Failing that, Xen should provide some other mechanism which would
enable something like update-grub to determine whether a particular
hypervisor can sensibly be run with a policy file and flask=enforcing.

Opinions?

Thanks,
Ian.

[1] osstest has been doing this approximately forever.  Due to
accidents of boot config ordering, these entries have not been used by
default.

Re: Xen XSM/FLASK policy, grub defaults, etc.

[George Dunlap]

> On May 27, 2020, at 4:41 PM, Ian Jackson <ian.jackson@citrix.com> wrote:
> 
> The Xen tools build system builds a FLASK policy by default.  It does
> this even if the hypervisor build for XSM is disabled.
> 
> I recently sent patches upstream to grub to support XSM in
> update-grub.  update-grub is the program which examines your /boot and
> generates appropriate bootloader entries.  My merge request
>  https://salsa.debian.org/grub-team/grub/-/merge_requests/18
> finds XSM policy files, and when theya are found, generates "XSM
> enabled" bootloader entries. [1]
> 
> The result of these two things together is that a default build of
> grub will result in these "XSM enabled" bootloader entries.  In
> practice I think these entries will boot because everything ignores
> the additional XSM policy file (!) and Xen ignores the
> "flask=enforcing" option (!!)
> 
> This is not particularly good.  Offering people an "XSM enabled"
> option which does nothing is poor because it might think they have the
> extra security but actually significantly more steps are needed.  But
> there doesn't appear to be any way for update-grub to tell whether a
> particular hypervisor does support XSM or not.
> 
> I think the following changes would be good:
> 
> 1. Xen should reject "flask=enforcing" if it is built without FLASK
> support, rather than ignoring it.  This will ensure users are not
> misled by these boot options since they will be broken.

+1

> 2. Xen should disable the XSM policy build when FLASK is disabled.
> This is unfortunately not so simple because the XSM policy build is a
> tools option and FLASK is a Xen option and the configuration systems
> are disjoint.  But at the very least a default build, which has no XSM
> support, should not build an XSM policy file either.

A simple thing to do here would be to have the flask policy controlled by a configure --flask option.  If neither --flask nor --no-flask is specified, we could maybe have configure also check the contents of xen/.config to see if CONFIG_XSM_FLASK is enabled?

> 3. Failing that, Xen should provide some other mechanism which would
> enable something like update-grub to determine whether a particular
> hypervisor can sensibly be run with a policy file and flask=enforcing.

So you want update-grub to check whether *the Xen binary it’s creating entries for* has FLASK enabled.  We generally include the Xen config used to build the hypervisor — could we have it check for CONFIG_XSM_FLASK?

 -George

Re: Xen XSM/FLASK policy, grub defaults, etc.

[Jan Beulich]

On 27.05.2020 18:08, George Dunlap wrote:
>> On May 27, 2020, at 4:41 PM, Ian Jackson <ian.jackson@citrix.com> wrote:
>> 2. Xen should disable the XSM policy build when FLASK is disabled.
>> This is unfortunately not so simple because the XSM policy build is a
>> tools option and FLASK is a Xen option and the configuration systems
>> are disjoint.  But at the very least a default build, which has no XSM
>> support, should not build an XSM policy file either.
> 
> A simple thing to do here would be to have the flask policy controlled by a configure --flask option.  If neither --flask nor --no-flask is specified, we could maybe have configure also check the contents of xen/.config to see if CONFIG_XSM_FLASK is enabled?

But that's creating a chicken-and-egg problem: There's no ordering
between the tools/ and xen/ builds. xen/ may not be built at all,
and this is going to become increasingly likely once the xen/ part
of the tree supports out-of-tree builds (at least I'll switch most
of my build trees to that model as soon as it's available).

Do we perhaps need to resort to a make command line option, usable
at the top level as well as for major subtree builds, and being
honored (as long as set either way, falling back to current
behavior if unset) by both ./configure and the hypervisor's
Kconfig?

Jan

Re: Xen XSM/FLASK policy, grub defaults, etc.

[Jan Beulich]

On 27.05.2020 18:08, George Dunlap wrote:
>> On May 27, 2020, at 4:41 PM, Ian Jackson <ian.jackson@citrix.com> wrote:
>>
>> The Xen tools build system builds a FLASK policy by default.  It does
>> this even if the hypervisor build for XSM is disabled.
>>
>> I recently sent patches upstream to grub to support XSM in
>> update-grub.  update-grub is the program which examines your /boot and
>> generates appropriate bootloader entries.  My merge request
>>  https://salsa.debian.org/grub-team/grub/-/merge_requests/18
>> finds XSM policy files, and when theya are found, generates "XSM
>> enabled" bootloader entries. [1]
>>
>> The result of these two things together is that a default build of
>> grub will result in these "XSM enabled" bootloader entries.  In
>> practice I think these entries will boot because everything ignores
>> the additional XSM policy file (!) and Xen ignores the
>> "flask=enforcing" option (!!)
>>
>> This is not particularly good.  Offering people an "XSM enabled"
>> option which does nothing is poor because it might think they have the
>> extra security but actually significantly more steps are needed.  But
>> there doesn't appear to be any way for update-grub to tell whether a
>> particular hypervisor does support XSM or not.
>>
>> I think the following changes would be good:
>>
>> 1. Xen should reject "flask=enforcing" if it is built without FLASK
>> support, rather than ignoring it.  This will ensure users are not
>> misled by these boot options since they will be broken.
> 
> +1

Yeah, probably better indeed, despite the current behavior being
documented correctly. I'll make a patch.

Jan

Re: Xen XSM/FLASK policy, grub defaults, etc.

[George Dunlap]

> On May 29, 2020, at 9:52 AM, Jan Beulich <jbeulich@suse.com> wrote:
> 
> On 27.05.2020 18:08, George Dunlap wrote:
>>> On May 27, 2020, at 4:41 PM, Ian Jackson <ian.jackson@citrix.com> wrote:
>>> 2. Xen should disable the XSM policy build when FLASK is disabled.
>>> This is unfortunately not so simple because the XSM policy build is a
>>> tools option and FLASK is a Xen option and the configuration systems
>>> are disjoint.  But at the very least a default build, which has no XSM
>>> support, should not build an XSM policy file either.
>> 
>> A simple thing to do here would be to have the flask policy controlled by a configure --flask option.  If neither --flask nor --no-flask is specified, we could maybe have configure also check the contents of xen/.config to see if CONFIG_XSM_FLASK is enabled?
> 
> But that's creating a chicken-and-egg problem: There's no ordering
> between the tools/ and xen/ builds. xen/ may not be built at all,
> and this is going to become increasingly likely once the xen/ part
> of the tree supports out-of-tree builds (at least I'll switch most
> of my build trees to that model as soon as it's available).

Do out-of-tree builds put the .config out of tree as well?  If so, yes, that would definitely limit the usefulness of this idea.

My suggestion was based on the idea that a “typical” build *which might enable XSM* would look like this:

1. Run ‘make menuconfig’ (or something like it) in xen/

2. Run ./configure at the toplevel

3. Do the full build.

But looking back at it, there’s no particular reason that someone coming to build Xen might expect to do things in that order rather than #1.

It might make sense to simply declare that the tools depend on the xen config, and modifying ./configure to represent that:

1. Add a `—xen-config=` option to configure telling it where to look for the xen config; if that’s not specified, look for a specific shell variable saying where the Xen tree is; if that’s not available, looking in the current tree.

2. Have ./configure fail by default if it can’t find a .config, unless —no-xen-config is specified.

> Do we perhaps need to resort to a make command line option, usable
> at the top level as well as for major subtree builds, and being
> honored (as long as set either way, falling back to current
> behavior if unset) by both ./configure and the hypervisor's
> Kconfig?

What kind of command-line option did you have in mind?

 -George

Re: Xen XSM/FLASK policy, grub defaults, etc.

[Jan Beulich]

On 29.05.2020 11:55, George Dunlap wrote:
> 
> 
>> On May 29, 2020, at 9:52 AM, Jan Beulich <jbeulich@suse.com> wrote:
>>
>> On 27.05.2020 18:08, George Dunlap wrote:
>>>> On May 27, 2020, at 4:41 PM, Ian Jackson <ian.jackson@citrix.com> wrote:
>>>> 2. Xen should disable the XSM policy build when FLASK is disabled.
>>>> This is unfortunately not so simple because the XSM policy build is a
>>>> tools option and FLASK is a Xen option and the configuration systems
>>>> are disjoint.  But at the very least a default build, which has no XSM
>>>> support, should not build an XSM policy file either.
>>>
>>> A simple thing to do here would be to have the flask policy controlled by a configure --flask option.  If neither --flask nor --no-flask is specified, we could maybe have configure also check the contents of xen/.config to see if CONFIG_XSM_FLASK is enabled?
>>
>> But that's creating a chicken-and-egg problem: There's no ordering
>> between the tools/ and xen/ builds. xen/ may not be built at all,
>> and this is going to become increasingly likely once the xen/ part
>> of the tree supports out-of-tree builds (at least I'll switch most
>> of my build trees to that model as soon as it's available).
> 
> Do out-of-tree builds put the .config out of tree as well?  If so, yes, that would definitely limit the usefulness of this idea.

Yes, all output files go into the build tree, to keep the source tree
clean. And .config is effectively an output file, despite it possibly
getting pre-populated into the build tree.

> My suggestion was based on the idea that a “typical” build *which might enable XSM* would look like this:
> 
> 1. Run ‘make menuconfig’ (or something like it) in xen/
> 
> 2. Run ./configure at the toplevel
> 
> 3. Do the full build.
> 
> But looking back at it, there’s no particular reason that someone coming to build Xen might expect to do things in that order rather than #1.
> 
> It might make sense to simply declare that the tools depend on the xen config, and modifying ./configure to represent that:
> 
> 1. Add a `—xen-config=` option to configure telling it where to look for the xen config; if that’s not specified, look for a specific shell variable saying where the Xen tree is; if that’s not available, looking in the current tree.
> 
> 2. Have ./configure fail by default if it can’t find a .config, unless —no-xen-config is specified.

Hmm, yes, that's certainly an option. The intended behavior with
--no-xen-config would be of interest though: Just what it is
now, i.e. controlled by yet another configure option?

>> Do we perhaps need to resort to a make command line option, usable
>> at the top level as well as for major subtree builds, and being
>> honored (as long as set either way, falling back to current
>> behavior if unset) by both ./configure and the hypervisor's
>> Kconfig?
> 
> What kind of command-line option did you have in mind?

Something like "XSM_FLASK=y".

Jan

Re: Xen XSM/FLASK policy, grub defaults, etc.

[Ian Jackson]

George Dunlap writes ("Re: Xen XSM/FLASK policy, grub defaults, etc."):
> > On May 27, 2020, at 4:41 PM, Ian Jackson <ian.jackson@citrix.com> wrote:
> > 3. Failing that, Xen should provide some other mechanism which would
> > enable something like update-grub to determine whether a particular
> > hypervisor can sensibly be run with a policy file and flask=enforcing.
> 
> So you want update-grub to check whether *the Xen binary it’s creating entries for* has FLASK enabled.  We generally include the Xen config used to build the hypervisor — could we have it check for CONFIG_XSM_FLASK?

That would be a possibility.  Including kernel configs has gone out of
fashion but I think most distros ship them.

Are we confident that this config name will remain stable ?

And I guess if the .config can't be found then the XSM boot entry
should be included ?

Ian.

Re: Xen XSM/FLASK policy, grub defaults, etc.

[Ian Jackson]

Ian Jackson writes ("Re: Xen XSM/FLASK policy, grub defaults, etc."):
> George Dunlap writes ("Re: Xen XSM/FLASK policy, grub defaults, etc."):
> > > On May 27, 2020, at 4:41 PM, Ian Jackson <ian.jackson@citrix.com> wrote:
> > > 3. Failing that, Xen should provide some other mechanism which would
> > > enable something like update-grub to determine whether a particular
> > > hypervisor can sensibly be run with a policy file and flask=enforcing.
> > 
> > So you want update-grub to check whether *the Xen binary it’s creating entries for* has FLASK enabled.  We generally include the Xen config used to build the hypervisor — could we have it check for CONFIG_XSM_FLASK?
> 
> That would be a possibility.  Including kernel configs has gone out of
> fashion but I think most distros ship them.

I mean most distros ship *Xen* configs even if they don't ship *Linux*
ones.

Ian.

Re: Xen XSM/FLASK policy, grub defaults, etc.

[George Dunlap]

> On May 29, 2020, at 11:50 AM, Ian Jackson <ian.jackson@citrix.com> wrote:
> 
> George Dunlap writes ("Re: Xen XSM/FLASK policy, grub defaults, etc."):
>>> On May 27, 2020, at 4:41 PM, Ian Jackson <ian.jackson@citrix.com> wrote:
>>> 3. Failing that, Xen should provide some other mechanism which would
>>> enable something like update-grub to determine whether a particular
>>> hypervisor can sensibly be run with a policy file and flask=enforcing.
>> 
>> So you want update-grub to check whether *the Xen binary it’s creating entries for* has FLASK enabled.  We generally include the Xen config used to build the hypervisor — could we have it check for CONFIG_XSM_FLASK?
> 
> That would be a possibility.  Including kernel configs has gone out of
> fashion but I think most distros ship them.
> 
> Are we confident that this config name will remain stable ?

Before taking this approach, we should probably agree to declare it stable, and write a comment to that effect in the Kconfig files.

> 
> And I guess if the .config can't be found then the XSM boot entry
> should be included ?

It looks like at the moment experimental config entries are “unpersons” without CONFIG_EXPERIMENTAL=y; at least, `rm .config && make defconfig && grep -i flask` doesn’t turn up anything for me.

 -George

Re: Xen XSM/FLASK policy, grub defaults, etc.

[Jan Beulich]

On 29.05.2020 12:50, Ian Jackson wrote:
> George Dunlap writes ("Re: Xen XSM/FLASK policy, grub defaults, etc."):
>>> On May 27, 2020, at 4:41 PM, Ian Jackson <ian.jackson@citrix.com> wrote:
>>> 3. Failing that, Xen should provide some other mechanism which would
>>> enable something like update-grub to determine whether a particular
>>> hypervisor can sensibly be run with a policy file and flask=enforcing.
>>
>> So you want update-grub to check whether *the Xen binary it’s creating entries for* has FLASK enabled.  We generally include the Xen config used to build the hypervisor — could we have it check for CONFIG_XSM_FLASK?
> 
> That would be a possibility.  Including kernel configs has gone out of
> fashion but I think most distros ship them.
> 
> Are we confident that this config name will remain stable ?

Well, if it's to be used like this, then we'll have to keep it
stable if at all possible. But that's the reason why I dislike
the .config grep-ing approach (not just for Xen, also for
Linux). It would imo be better if the binary included something
that can be queried. Such a "something" is then much more
logical to keep stable, imo. This "something" could be an ELF
note, for example (assuming a similar problem to the one here
doesn't exist for xen.efi, or else we'd need to find a solution
there, too).

Jan

Re: Xen XSM/FLASK policy, grub defaults, etc.

[George Dunlap]

> On May 29, 2020, at 12:02 PM, Jan Beulich <jbeulich@suse.com> wrote:
> 
> On 29.05.2020 12:50, Ian Jackson wrote:
>> George Dunlap writes ("Re: Xen XSM/FLASK policy, grub defaults, etc."):
>>>> On May 27, 2020, at 4:41 PM, Ian Jackson <ian.jackson@citrix.com> wrote:
>>>> 3. Failing that, Xen should provide some other mechanism which would
>>>> enable something like update-grub to determine whether a particular
>>>> hypervisor can sensibly be run with a policy file and flask=enforcing.
>>> 
>>> So you want update-grub to check whether *the Xen binary it’s creating entries for* has FLASK enabled.  We generally include the Xen config used to build the hypervisor — could we have it check for CONFIG_XSM_FLASK?
>> 
>> That would be a possibility.  Including kernel configs has gone out of
>> fashion but I think most distros ship them.
>> 
>> Are we confident that this config name will remain stable ?
> 
> Well, if it's to be used like this, then we'll have to keep it
> stable if at all possible. But that's the reason why I dislike
> the .config grep-ing approach (not just for Xen, also for
> Linux). It would imo be better if the binary included something
> that can be queried. Such a "something" is then much more
> logical to keep stable, imo. This "something" could be an ELF
> note, for example (assuming a similar problem to the one here
> doesn't exist for xen.efi, or else we'd need to find a solution
> there, too).

I think an elf note on the binary would be nice; but it won’t help until all the distros pick up Xen 4.15.

Which isn’t to say we shouldn’t do it; but it might be nice to also have an intermediate solution that works right now, even if it’s not optimal.

 -George

Re: Xen XSM/FLASK policy, grub defaults, etc.

[Ian Jackson]

George Dunlap writes ("Re: Xen XSM/FLASK policy, grub defaults, etc."):
> Which isn’t to say we shouldn’t do it; but it might be nice to also have an intermediate solution that works right now, even if it’s not optimal.

I propose the following behaviour by updste-grub:

 1. Look for an ELF note, TBD.  If it's found, make XSM boot entries.
    (For now, skip this step, since the ELF note is not defined.)

 2. Look for a .config alongside the Xen binary.  Look for
       ^CONFIG_XSM_FLASK=y
    If the file is is not found, or no line matches, make no XSM
    boot entries.

Ian.

Re: Xen XSM/FLASK policy, grub defaults, etc.

[Jan Beulich]

On 29.05.2020 16:47, Ian Jackson wrote:
> George Dunlap writes ("Re: Xen XSM/FLASK policy, grub defaults, etc."):
>> Which isn’t to say we shouldn’t do it; but it might be nice to also have an intermediate solution that works right now, even if it’s not optimal.
> 
> I propose the following behaviour by updste-grub:
> 
>  1. Look for an ELF note, TBD.  If it's found, make XSM boot entries.
>     (For now, skip this step, since the ELF note is not defined.)
> 
>  2. Look for a .config alongside the Xen binary.  Look for
>        ^CONFIG_XSM_FLASK=y
>     If the file is is not found, or no line matches, make no XSM
>     boot entries.

Sounds like a plan then, I think.

Jan

Re: Xen XSM/FLASK policy, grub defaults, etc.

[Julien Grall]

Hi Ian,

On 29/05/2020 15:47, Ian Jackson wrote:
> George Dunlap writes ("Re: Xen XSM/FLASK policy, grub defaults, etc."):
>> Which isn’t to say we shouldn’t do it; but it might be nice to also have an intermediate solution that works right now, even if it’s not optimal.
> 
> I propose the following behaviour by updste-grub:
> 
>   1. Look for an ELF note, TBD.  If it's found, make XSM boot entries.
>      (For now, skip this step, since the ELF note is not defined.)

I am afraid the ELF note is a very x86 thing. On Arm, we don't have such 
thing for the kernel/xen (actually the final binary is not even an ELF).

> 
>   2. Look for a .config alongside the Xen binary.  Look for
>         ^CONFIG_XSM_FLASK=y
>      If the file is is not found, or no line matches, make no XSM
>      boot entries.

... this would probably be the best solution for Arm.

Cheers,

-- 
Julien Grall

Re: Xen XSM/FLASK policy, grub defaults, etc.

[Jan Beulich]

On 29.05.2020 17:05, Julien Grall wrote:
> On 29/05/2020 15:47, Ian Jackson wrote:
>> George Dunlap writes ("Re: Xen XSM/FLASK policy, grub defaults, etc."):
>>> Which isn’t to say we shouldn’t do it; but it might be nice to also have an intermediate solution that works right now, even if it’s not optimal.
>>
>> I propose the following behaviour by updste-grub:
>>
>>   1. Look for an ELF note, TBD.  If it's found, make XSM boot entries.
>>      (For now, skip this step, since the ELF note is not defined.)
> 
> I am afraid the ELF note is a very x86 thing. On Arm, we don't have such 
> thing for the kernel/xen (actually the final binary is not even an ELF).

Ouch - of course. Is there anything similar one could employ there?

Jan

Re: Xen XSM/FLASK policy, grub defaults, etc.

[Julien Grall]

Hi Jan,

On 29/05/2020 16:11, Jan Beulich wrote:
> On 29.05.2020 17:05, Julien Grall wrote:
>> On 29/05/2020 15:47, Ian Jackson wrote:
>>> George Dunlap writes ("Re: Xen XSM/FLASK policy, grub defaults, etc."):
>>>> Which isn’t to say we shouldn’t do it; but it might be nice to also have an intermediate solution that works right now, even if it’s not optimal.
>>>
>>> I propose the following behaviour by updste-grub:
>>>
>>>    1. Look for an ELF note, TBD.  If it's found, make XSM boot entries.
>>>       (For now, skip this step, since the ELF note is not defined.)
>>
>> I am afraid the ELF note is a very x86 thing. On Arm, we don't have such
>> thing for the kernel/xen (actually the final binary is not even an ELF).
> 
> Ouch - of course. Is there anything similar one could employ there?

In the past, we discussed about adding support for note in the zImage 
(arm32 kernel format) but I never got the chance to pursue the discussion.

With Juergen's hypfs series, the hypervisor now embbed the .config. Is 
it possible to extract it?

Cheers,

-- 
Julien Grall

Re: Xen XSM/FLASK policy, grub defaults, etc.

[George Dunlap]

> On May 29, 2020, at 6:24 PM, Julien Grall <julien@xen.org> wrote:
> 
> Hi Jan,
> 
> On 29/05/2020 16:11, Jan Beulich wrote:
>> On 29.05.2020 17:05, Julien Grall wrote:
>>> On 29/05/2020 15:47, Ian Jackson wrote:
>>>> George Dunlap writes ("Re: Xen XSM/FLASK policy, grub defaults, etc."):
>>>>> Which isn’t to say we shouldn’t do it; but it might be nice to also have an intermediate solution that works right now, even if it’s not optimal.
>>>> 
>>>> I propose the following behaviour by updste-grub:
>>>> 
>>>>   1. Look for an ELF note, TBD.  If it's found, make XSM boot entries.
>>>>      (For now, skip this step, since the ELF note is not defined.)
>>> 
>>> I am afraid the ELF note is a very x86 thing. On Arm, we don't have such
>>> thing for the kernel/xen (actually the final binary is not even an ELF).
>> Ouch - of course. Is there anything similar one could employ there?
> 
> In the past, we discussed about adding support for note in the zImage (arm32 kernel format) but I never got the chance to pursue the discussion.
> 
> With Juergen's hypfs series, the hypervisor now embbed the .config. Is it possible to extract it?

The problem is that update-grub doesn’t want the config of the *currently running* hypervisor, but of whatever specific hypervisor there is in /boot.

So for instance, when someone first does “apt-get install xen”, after xen binaries are put in /boot, update-grub is called to make new entries for it.  Ideally, we want it to create FLASK grub entries, and boot them by default, if and only if *that Xen binary* has FLASK enabled and there is a policy for it.  At the time update-grub runs, Xen will not be running.

And if a user installs several Xen binaries, some of which have FLASK enabled and some of which don’t, we want update-grub to generate FLASK entries for the binaries that have FLASK enabled, and not for the ones which don’t.  So hypfs isn’t really a suitable solution.

The options proposed have included:

1. Making the tools not generate a FLASK policy unless FLASK is enabled in the hypervisor being built.  This is flaky because there’s no necessary connection between the two builds.

2. Using the xen config file normally copied into /boot.  This should work now, but it’s been suggested that packagers may not want to continue putting the xen config in /boot along with xen.gz, just as they’ve stopped putting the Linux config in /boot along with vmlinuz.

3. Mark the xen.gz binary itself somehow as having FLASK.  This could work for x86 in the future, but won’t work for current binaries; and it sounds like it won’t work for ARM either.

Ultimately, I have the feeling that #1, although somewhat awkward, is going to be the best solution: packagers can arrange that FLASK policies only be installed when FLASK policies are created.  People doing self-builds based on distro packages will be covered; people doing home-grown self-builds with non-default FLASK settings will need to take extra care to make sure the tools do the right thing.

 -George

Re: Xen XSM/FLASK policy, grub defaults, etc.

[Julien Grall]

Hi George,

On 01/06/2020 13:57, George Dunlap wrote:
> 
> 
>> On May 29, 2020, at 6:24 PM, Julien Grall <julien@xen.org> wrote:
>>
>> Hi Jan,
>>
>> On 29/05/2020 16:11, Jan Beulich wrote:
>>> On 29.05.2020 17:05, Julien Grall wrote:
>>>> On 29/05/2020 15:47, Ian Jackson wrote:
>>>>> George Dunlap writes ("Re: Xen XSM/FLASK policy, grub defaults, etc."):
>>>>>> Which isn’t to say we shouldn’t do it; but it might be nice to also have an intermediate solution that works right now, even if it’s not optimal.
>>>>>
>>>>> I propose the following behaviour by updste-grub:
>>>>>
>>>>>    1. Look for an ELF note, TBD.  If it's found, make XSM boot entries.
>>>>>       (For now, skip this step, since the ELF note is not defined.)
>>>>
>>>> I am afraid the ELF note is a very x86 thing. On Arm, we don't have such
>>>> thing for the kernel/xen (actually the final binary is not even an ELF).
>>> Ouch - of course. Is there anything similar one could employ there?
>>
>> In the past, we discussed about adding support for note in the zImage (arm32 kernel format) but I never got the chance to pursue the discussion.
>>
>> With Juergen's hypfs series, the hypervisor now embbed the .config. Is it possible to extract it?
> 
> The problem is that update-grub doesn’t want the config of the *currently running* hypervisor, but of whatever specific hypervisor there is in /boot. >
> So for instance, when someone first does “apt-get install xen”, after xen binaries are put in /boot, update-grub is called to make new entries for it.  Ideally, we want it to create FLASK grub entries, and boot them by default, if and only if *that Xen binary* has FLASK enabled and there is a policy for it.  At the time update-grub runs, Xen will not be running.

I am fully aware we want to get information of the binaries residing in 
/boot (I wouldn't have suggested zImage note otherwise). So I think you 
misundertood my question.

> 
> And if a user installs several Xen binaries, some of which have FLASK enabled and some of which don’t, we want update-grub to generate FLASK entries for the binaries that have FLASK enabled, and not for the ones which don’t.  So hypfs isn’t really a suitable solution.

I have never suggested to use hypfs. Instead, I have pointed out that 
.config is embedded in the binary thanks to hypfs. So I was asking 
whether we can extract it.

On Linux, they have a script to extract the .config from the Kernel 
Image (see scripts/extract-ikconfig). Now that the .config is part of 
the Xen binarry, I was wondering whether we could have extract it.

> 
> The options proposed have included:
> 
> 1. Making the tools not generate a FLASK policy unless FLASK is enabled in the hypervisor being built.  This is flaky because there’s no necessary connection between the two builds.
> 
> 2. Using the xen config file normally copied into /boot.  This should work now, but it’s been suggested that packagers may not want to continue putting the xen config in /boot along with xen.gz, just as they’ve stopped putting the Linux config in /boot along with vmlinuz.
> 
> 3. Mark the xen.gz binary itself somehow as having FLASK.  This could work for x86 in the future, but won’t work for current binaries; and it sounds like it won’t work for ARM either.

4. Extract the .config from the binary using a similar script to 
script/extract-ikconfig.

Cheers,

-- 
Julien Grall

Re: Xen XSM/FLASK policy, grub defaults, etc.

[George Dunlap]

> On Jun 1, 2020, at 2:10 PM, Julien Grall <julien@xen.org> wrote:
> 4. Extract the .config from the binary using a similar script to script/extract-ikconfig.

Ah, gotcha.  I did misunderstand your suggestion.

 -George

Re: Xen XSM/FLASK policy, grub defaults, etc.

[Julien Grall]

On 01/06/2020 14:35, George Dunlap wrote:
> 
> 
>> On Jun 1, 2020, at 2:10 PM, Julien Grall <julien@xen.org> wrote:
>> 4. Extract the .config from the binary using a similar script to script/extract-ikconfig.
> 
> Ah, gotcha.  I did misunderstand your suggestion.
The advantage I can see with this solution is this is arch agnostic and 
can be easily extend to other options. But it also means at least some 
of CONFIG_* needs to be stable.

Can this solution be an alternative to the ELF note?

Cheers,

-- 
Julien Grall

Re: Xen XSM/FLASK policy, grub defaults, etc.

[Ian Jackson]

George Dunlap writes ("Re: Xen XSM/FLASK policy, grub defaults, etc."):
> The options proposed have included:

Thanks for summarising!

> 1. Making the tools not generate a FLASK policy unless FLASK is enabled in the hypervisor being built.  This is flaky because there’s no necessary connection between the two builds.
...
> Ultimately, I have the feeling that #1, although somewhat awkward, is going to be the best solution: packagers can arrange that FLASK policies only be installed when FLASK policies are created.  People doing self-builds based on distro packages will be covered; people doing home-grown self-builds with non-default FLASK settings will need to take extra care to make sure the tools do the right thing.

For these home-grown self-builds, making `flask=enforcing' the default
boot entry will make the resulting entry not boot.  So ISTM that
`flask=enforcing' cannot be in the default boot entry unless it's
*known* that FLASK is enabled in the hypervisor.

(Right now update-grub does not make the XSM entries the default, but
clearly it would be better for it to do so if FLASK is enabled.)

Adding the /boot/<xen>.config fallback to update-grub now risks
accidentally going back to non-FLASK booting at some future point when
the xen packager decides not to ship the .config any more...

Ian.

Re: Xen XSM/FLASK policy, grub defaults, etc.

[Jan Beulich]

On 29.05.2020 19:24, Julien Grall wrote:
> On 29/05/2020 16:11, Jan Beulich wrote:
>> On 29.05.2020 17:05, Julien Grall wrote:
>>> On 29/05/2020 15:47, Ian Jackson wrote:
>>>> George Dunlap writes ("Re: Xen XSM/FLASK policy, grub defaults, etc."):
>>>>> Which isn’t to say we shouldn’t do it; but it might be nice to also have an intermediate solution that works right now, even if it’s not optimal.
>>>>
>>>> I propose the following behaviour by updste-grub:
>>>>
>>>>    1. Look for an ELF note, TBD.  If it's found, make XSM boot entries.
>>>>       (For now, skip this step, since the ELF note is not defined.)
>>>
>>> I am afraid the ELF note is a very x86 thing. On Arm, we don't have such
>>> thing for the kernel/xen (actually the final binary is not even an ELF).
>>
>> Ouch - of course. Is there anything similar one could employ there?
> 
> In the past, we discussed about adding support for note in the zImage 
> (arm32 kernel format) but I never got the chance to pursue the discussion.
> 
> With Juergen's hypfs series, the hypervisor now embbed the .config. Is 
> it possible to extract it?

How easy is it to reliably find a random blob of gzip-ed data in an
otherwise unstructured (as in: no ELF sections, and hence no way to
put the data of interest into a separate section for easy
recognition) binary? Also don't forget that the embedding of .config
is an optional thing.

Jan

Re: Xen XSM/FLASK policy, grub defaults, etc.

[Julien Grall]

On 02/06/2020 08:21, Jan Beulich wrote:
> On 29.05.2020 19:24, Julien Grall wrote:
>> On 29/05/2020 16:11, Jan Beulich wrote:
>>> On 29.05.2020 17:05, Julien Grall wrote:
>>>> On 29/05/2020 15:47, Ian Jackson wrote:
>>>>> George Dunlap writes ("Re: Xen XSM/FLASK policy, grub defaults, etc."):
>>>>>> Which isn’t to say we shouldn’t do it; but it might be nice to also have an intermediate solution that works right now, even if it’s not optimal.
>>>>>
>>>>> I propose the following behaviour by updste-grub:
>>>>>
>>>>>     1. Look for an ELF note, TBD.  If it's found, make XSM boot entries.
>>>>>        (For now, skip this step, since the ELF note is not defined.)
>>>>
>>>> I am afraid the ELF note is a very x86 thing. On Arm, we don't have such
>>>> thing for the kernel/xen (actually the final binary is not even an ELF).
>>>
>>> Ouch - of course. Is there anything similar one could employ there?
>>
>> In the past, we discussed about adding support for note in the zImage
>> (arm32 kernel format) but I never got the chance to pursue the discussion.
>>
>> With Juergen's hypfs series, the hypervisor now embbed the .config. Is
>> it possible to extract it?
> 
> How easy is it to reliably find a random blob of gzip-ed data in an
> otherwise unstructured (as in: no ELF sections, and hence no way to
> put the data of interest into a separate section for easy
> recognition) binary?

As I pointed out in another reply, Linux is already doing it (see 
scripts/extract-ikconfig). In fact I was able to extract the .config 
from an Linux Arm64 Image.

AFAICT, Linux will look up with to specific value in the kernel image 
which surround the gzipped .config.

If Linux is able to do it, then we should be able to do it. I don't know 
whether this is 100% reliable, however we could make sure your .config 
is towards the end of the image. So it reduces the chance you find 
something different.

> Also don't forget that the embedding of .config
> is an optional thing.

I don't really see this as a blocker. Embedding the .config can be made 
mandatory going forward. This is not going to significantly increase the 
size of Xen and would help to when debugging as you could exactly know 
which .config was used.

Cheers,

-- 
Julien Grall

Re: Xen XSM/FLASK policy, grub defaults, etc.

[Jürgen Groß]

On 02.06.20 10:26, Julien Grall wrote:
> 
> 
> On 02/06/2020 08:21, Jan Beulich wrote:
>> On 29.05.2020 19:24, Julien Grall wrote:
>>> On 29/05/2020 16:11, Jan Beulich wrote:
>>>> On 29.05.2020 17:05, Julien Grall wrote:
>>>>> On 29/05/2020 15:47, Ian Jackson wrote:
>>>>>> George Dunlap writes ("Re: Xen XSM/FLASK policy, grub defaults, 
>>>>>> etc."):
>>>>>>> Which isn’t to say we shouldn’t do it; but it might be nice to 
>>>>>>> also have an intermediate solution that works right now, even if 
>>>>>>> it’s not optimal.
>>>>>>
>>>>>> I propose the following behaviour by updste-grub:
>>>>>>
>>>>>>     1. Look for an ELF note, TBD.  If it's found, make XSM boot 
>>>>>> entries.
>>>>>>        (For now, skip this step, since the ELF note is not defined.)
>>>>>
>>>>> I am afraid the ELF note is a very x86 thing. On Arm, we don't have 
>>>>> such
>>>>> thing for the kernel/xen (actually the final binary is not even an 
>>>>> ELF).
>>>>
>>>> Ouch - of course. Is there anything similar one could employ there?
>>>
>>> In the past, we discussed about adding support for note in the zImage
>>> (arm32 kernel format) but I never got the chance to pursue the 
>>> discussion.
>>>
>>> With Juergen's hypfs series, the hypervisor now embbed the .config. Is
>>> it possible to extract it?
>>
>> How easy is it to reliably find a random blob of gzip-ed data in an
>> otherwise unstructured (as in: no ELF sections, and hence no way to
>> put the data of interest into a separate section for easy
>> recognition) binary?
> 
> As I pointed out in another reply, Linux is already doing it (see 
> scripts/extract-ikconfig). In fact I was able to extract the .config 
> from an Linux Arm64 Image.
> 
> AFAICT, Linux will look up with to specific value in the kernel image 
> which surround the gzipped .config.
> 
> If Linux is able to do it, then we should be able to do it. I don't know 
> whether this is 100% reliable, however we could make sure your .config 
> is towards the end of the image. So it reduces the chance you find 
> something different.
> 
>> Also don't forget that the embedding of .config
>> is an optional thing.
> 
> I don't really see this as a blocker. Embedding the .config can be made 
> mandatory going forward. This is not going to significantly increase the 
> size of Xen and would help to when debugging as you could exactly know 
> which .config was used.

If you can find an embedded .config via a special pattern you can just
define a pattern and embed that only in case of a flask-enabled Xen.
This would remove the need to make the config option a stable ABI.


Juergen

Re: Xen XSM/FLASK policy, grub defaults, etc.

[Julien Grall]

Hi Juergen,

On 02/06/2020 09:30, Jürgen Groß wrote:
> On 02.06.20 10:26, Julien Grall wrote:
>>
>>
>> On 02/06/2020 08:21, Jan Beulich wrote:
>>> On 29.05.2020 19:24, Julien Grall wrote:
>>>> On 29/05/2020 16:11, Jan Beulich wrote:
>>>>> On 29.05.2020 17:05, Julien Grall wrote:
>>>>>> On 29/05/2020 15:47, Ian Jackson wrote:
>>>>>>> George Dunlap writes ("Re: Xen XSM/FLASK policy, grub defaults, 
>>>>>>> etc."):
>>>>>>>> Which isn’t to say we shouldn’t do it; but it might be nice to 
>>>>>>>> also have an intermediate solution that works right now, even if 
>>>>>>>> it’s not optimal.
>>>>>>>
>>>>>>> I propose the following behaviour by updste-grub:
>>>>>>>
>>>>>>>     1. Look for an ELF note, TBD.  If it's found, make XSM boot 
>>>>>>> entries.
>>>>>>>        (For now, skip this step, since the ELF note is not defined.)
>>>>>>
>>>>>> I am afraid the ELF note is a very x86 thing. On Arm, we don't 
>>>>>> have such
>>>>>> thing for the kernel/xen (actually the final binary is not even an 
>>>>>> ELF).
>>>>>
>>>>> Ouch - of course. Is there anything similar one could employ there?
>>>>
>>>> In the past, we discussed about adding support for note in the zImage
>>>> (arm32 kernel format) but I never got the chance to pursue the 
>>>> discussion.
>>>>
>>>> With Juergen's hypfs series, the hypervisor now embbed the .config. Is
>>>> it possible to extract it?
>>>
>>> How easy is it to reliably find a random blob of gzip-ed data in an
>>> otherwise unstructured (as in: no ELF sections, and hence no way to
>>> put the data of interest into a separate section for easy
>>> recognition) binary?
>>
>> As I pointed out in another reply, Linux is already doing it (see 
>> scripts/extract-ikconfig). In fact I was able to extract the .config 
>> from an Linux Arm64 Image.
>>
>> AFAICT, Linux will look up with to specific value in the kernel image 
>> which surround the gzipped .config.
>>
>> If Linux is able to do it, then we should be able to do it. I don't 
>> know whether this is 100% reliable, however we could make sure your 
>> .config is towards the end of the image. So it reduces the chance you 
>> find something different.
>>
>>> Also don't forget that the embedding of .config
>>> is an optional thing.
>>
>> I don't really see this as a blocker. Embedding the .config can be 
>> made mandatory going forward. This is not going to significantly 
>> increase the size of Xen and would help to when debugging as you could 
>> exactly know which .config was used.
> 
> If you can find an embedded .config via a special pattern you can just
> define a pattern and embed that only in case of a flask-enabled Xen.

This is a fair point. However, this would be very specific to 
flask-enabled Xen. In that case, it might be better to consider a 
zImage/Image note style on Arm.

> This would remove the need to make the config option a stable ABI.

Cheers,

-- 
Julien Grall