Re: [RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub

[Gary Lin]

On Thu, Dec 07, 2017 at 02:26:57PM +, Alan Cox wrote:
> On Tue,  5 Dec 2017 18:01:46 +0800
> Gary Lin  wrote:
> 
> > The series of patches introduce Security Version to EFI stub.
> > 
> > Security Version is a monotonically increasing number and designed to
> > prevent the user from loading an insecure kernel accidentally. The
> > bootloader maintains a list of security versions corresponding to
> > different distributions. After fixing a critical vulnerability, the
> > distribution kernel maintainer bumps the "version", and the bootloader
> > updates the list automatically. 
> 
> This seems a mindbogglingly complicated way to implement something you
> could do with a trivial script in the package that updates the list of
> iffy kernels and when generating the new grub.conf puts them in a menu
> of 'old insecure' kernels.
> 
Ya, a menu for those kernels is also a kind of warning to the users.
Thanks for pointing the direction.

> Why do you even need this in the EFI stub ?
> 
For 2 reasons.

1. We want the version number being unalterable. In a system with UEFI
   Secure Boot, the signature appended to the kernel guarantees that the
   version number is genuine.

2. For the cross-architecture support. Since the version number could be
   anywhere in the image file, we need at least a offset to point to the
   version number. That's why I choose the resource section/table in the
   EFI header. It exists as long as the EFI stub exists. The design of
   the directory allows different data stored separately.

If there is a better place for the version number, I'd be glad to adopt
it.

> What happens if you want to invalidate an old kernel but not push a new
> one ? Today if you've got a package that maintains the list of 'iffy'
> kernels you can push a tiny package, under your scheme you've got to push
> new kernels which is an un-necessary and high risk OS change.
> 
The idea is that the security version only bumps only when it's really
necessary. For example, the new kernel fixes a severe bug that invalidates
the signature check of the modules. Or, the distro makes an official
release and would like to obsolete the alpha/beta/RC kernel. Anyway, it
depends on the distro policy.

Actually, our main target is only for the enterprise server, and the
kernel update path is relatively simple. Since it may bring some
confusion in a multi-boot system, we are currently not planning to
enable SV for the community distro, i.e. openSUSE.

Thanks,

Gary Lin

Re: [RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub

[Gary Lin]

On Thu, Dec 07, 2017 at 02:26:57PM +, Alan Cox wrote:
> On Tue,  5 Dec 2017 18:01:46 +0800
> Gary Lin  wrote:
> 
> > The series of patches introduce Security Version to EFI stub.
> > 
> > Security Version is a monotonically increasing number and designed to
> > prevent the user from loading an insecure kernel accidentally. The
> > bootloader maintains a list of security versions corresponding to
> > different distributions. After fixing a critical vulnerability, the
> > distribution kernel maintainer bumps the "version", and the bootloader
> > updates the list automatically. 
> 
> This seems a mindbogglingly complicated way to implement something you
> could do with a trivial script in the package that updates the list of
> iffy kernels and when generating the new grub.conf puts them in a menu
> of 'old insecure' kernels.
> 
Ya, a menu for those kernels is also a kind of warning to the users.
Thanks for pointing the direction.

> Why do you even need this in the EFI stub ?
> 
For 2 reasons.

1. We want the version number being unalterable. In a system with UEFI
   Secure Boot, the signature appended to the kernel guarantees that the
   version number is genuine.

2. For the cross-architecture support. Since the version number could be
   anywhere in the image file, we need at least a offset to point to the
   version number. That's why I choose the resource section/table in the
   EFI header. It exists as long as the EFI stub exists. The design of
   the directory allows different data stored separately.

If there is a better place for the version number, I'd be glad to adopt
it.

> What happens if you want to invalidate an old kernel but not push a new
> one ? Today if you've got a package that maintains the list of 'iffy'
> kernels you can push a tiny package, under your scheme you've got to push
> new kernels which is an un-necessary and high risk OS change.
> 
The idea is that the security version only bumps only when it's really
necessary. For example, the new kernel fixes a severe bug that invalidates
the signature check of the modules. Or, the distro makes an official
release and would like to obsolete the alpha/beta/RC kernel. Anyway, it
depends on the distro policy.

Actually, our main target is only for the enterprise server, and the
kernel update path is relatively simple. Since it may bring some
confusion in a multi-boot system, we are currently not planning to
enable SV for the community distro, i.e. openSUSE.

Thanks,

Gary Lin

Re: [RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub

[Gary Lin]

On Thu, Dec 07, 2017 at 11:35:52AM +0100, Ingo Molnar wrote:
> 
> 
> * Gary Lin  wrote:
> 
> > On Thu, Dec 07, 2017 at 09:18:16AM +0100, Ingo Molnar wrote:
> > > 
> > > * Gary Lin  wrote:
> > > 
> > > > On Thu, Dec 07, 2017 at 07:09:27AM +0100, Ingo Molnar wrote:
> > > > > 
> > > > > * Gary Lin  wrote:
> > > > > 
> > > > > > On Wed, Dec 06, 2017 at 07:37:34PM +0100, Ingo Molnar wrote:
> > > > > > > 
> > > > > > > * Gary Lin  wrote:
> > > > > > > 
> > > > > > > > On Tue, Dec 05, 2017 at 04:14:26PM -0500, Josh Boyer wrote:
> > > > > > > > > On Tue, Dec 5, 2017 at 5:01 AM, Gary Lin  
> > > > > > > > > wrote:
> > > > > > > > > > The series of patches introduce Security Version to EFI 
> > > > > > > > > > stub.
> > > > > > > > > >
> > > > > > > > > > Security Version is a monotonically increasing number and 
> > > > > > > > > > designed to
> > > > > > > > > > prevent the user from loading an insecure kernel 
> > > > > > > > > > accidentally. The
> > > > > > > > > > bootloader maintains a list of security versions 
> > > > > > > > > > corresponding to
> > > > > > > > > > different distributions. After fixing a critical 
> > > > > > > > > > vulnerability, the
> > > > > > > > > > distribution kernel maintainer bumps the "version", and the 
> > > > > > > > > > bootloader
> > > > > > > > > > updates the list automatically. When the user tries to load 
> > > > > > > > > > a kernel
> > > > > > > > > > with a lower security version, the bootloader shows a 
> > > > > > > > > > warning prompt
> > > > > > > > > > to notify the user the potential risk.
> > > > > > > > > 
> > > > > > > > > If a distribution releases a kernel with a higher security 
> > > > > > > > > version and
> > > > > > > > > that it automatically updated on boot, what happens if that 
> > > > > > > > > kernel
> > > > > > > > > contains a different bug that causes it to fail to boot or 
> > > > > > > > > break
> > > > > > > > > critical functionality?  At that point, the user's machine 
> > > > > > > > > would be in
> > > > > > > > > a state where the higher security version is enforced but the 
> > > > > > > > > only
> > > > > > > > > kernel that provides that is broken.  Wouldn't that make a bad
> > > > > > > > > situation even worse by now requiring manual acceptance of 
> > > > > > > > > the older
> > > > > > > > > SV kernel boot physically at the machine?
> > > > > > > > > 
> > > > > > > > > I feel like I'm missing a detail here or something.
> > > > > > > > > 
> > > > > > > > If the new kernel fails to boot, then the user has to choose 
> > > > > > > > the kernel
> > > > > > > > manually anyway, and there will be an option in the warning 
> > > > > > > > prompt to
> > > > > > > > lower SV.
> > > > > > > 
> > > > > > > And what if the firmware does not support a lowering of the SV?
> > > > > > > 
> > > > > > The SV list is manipulated by the bootloader, and the firmware only
> > > > > > provides the interface to the storage, i.e. non-volatile flash.
> > > > > 
> > > > > What about systems where the bootloader is part of the system and 
> > > > > users only have 
> > > > > the ability to provide kernel images, but no ability to change the 
> > > > > boot loader?
> > > > 
> > > > It depends on how the bootloader works. If the system uses my
> > > > implementation of shim loader, it surely has the ability to lower SV,
> > > > but it requires physical access on purpose.
> > > 
> > > And that's my problem: if in practice the bootloader is 'part of the 
> > > system', is 
> > > signed and is updated like the firmware, then putting a "Security 
> > > Version" into 
> > > the kernel image and architecting a boot protocol for a monotonic method 
> > > for the 
> > > bootloader to restrict the loading of kernel images is an obviously bad 
> > > idea.
> > > 
> > Even though the bootloader doesn't actually block the booting?
> 
> We don't know that for sure, in that scenario *how* the bootloader interprets 
> the 
> SV is not under the user's control...
> 
OK, it seems the implementation in shim brings up some concern. I'll
discuss with my colleagues for other possible solutions.

Cheers,

Gary Lin

Re: [RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub

[Gary Lin]

On Thu, Dec 07, 2017 at 11:35:52AM +0100, Ingo Molnar wrote:
> 
> 
> * Gary Lin  wrote:
> 
> > On Thu, Dec 07, 2017 at 09:18:16AM +0100, Ingo Molnar wrote:
> > > 
> > > * Gary Lin  wrote:
> > > 
> > > > On Thu, Dec 07, 2017 at 07:09:27AM +0100, Ingo Molnar wrote:
> > > > > 
> > > > > * Gary Lin  wrote:
> > > > > 
> > > > > > On Wed, Dec 06, 2017 at 07:37:34PM +0100, Ingo Molnar wrote:
> > > > > > > 
> > > > > > > * Gary Lin  wrote:
> > > > > > > 
> > > > > > > > On Tue, Dec 05, 2017 at 04:14:26PM -0500, Josh Boyer wrote:
> > > > > > > > > On Tue, Dec 5, 2017 at 5:01 AM, Gary Lin  
> > > > > > > > > wrote:
> > > > > > > > > > The series of patches introduce Security Version to EFI 
> > > > > > > > > > stub.
> > > > > > > > > >
> > > > > > > > > > Security Version is a monotonically increasing number and 
> > > > > > > > > > designed to
> > > > > > > > > > prevent the user from loading an insecure kernel 
> > > > > > > > > > accidentally. The
> > > > > > > > > > bootloader maintains a list of security versions 
> > > > > > > > > > corresponding to
> > > > > > > > > > different distributions. After fixing a critical 
> > > > > > > > > > vulnerability, the
> > > > > > > > > > distribution kernel maintainer bumps the "version", and the 
> > > > > > > > > > bootloader
> > > > > > > > > > updates the list automatically. When the user tries to load 
> > > > > > > > > > a kernel
> > > > > > > > > > with a lower security version, the bootloader shows a 
> > > > > > > > > > warning prompt
> > > > > > > > > > to notify the user the potential risk.
> > > > > > > > > 
> > > > > > > > > If a distribution releases a kernel with a higher security 
> > > > > > > > > version and
> > > > > > > > > that it automatically updated on boot, what happens if that 
> > > > > > > > > kernel
> > > > > > > > > contains a different bug that causes it to fail to boot or 
> > > > > > > > > break
> > > > > > > > > critical functionality?  At that point, the user's machine 
> > > > > > > > > would be in
> > > > > > > > > a state where the higher security version is enforced but the 
> > > > > > > > > only
> > > > > > > > > kernel that provides that is broken.  Wouldn't that make a bad
> > > > > > > > > situation even worse by now requiring manual acceptance of 
> > > > > > > > > the older
> > > > > > > > > SV kernel boot physically at the machine?
> > > > > > > > > 
> > > > > > > > > I feel like I'm missing a detail here or something.
> > > > > > > > > 
> > > > > > > > If the new kernel fails to boot, then the user has to choose 
> > > > > > > > the kernel
> > > > > > > > manually anyway, and there will be an option in the warning 
> > > > > > > > prompt to
> > > > > > > > lower SV.
> > > > > > > 
> > > > > > > And what if the firmware does not support a lowering of the SV?
> > > > > > > 
> > > > > > The SV list is manipulated by the bootloader, and the firmware only
> > > > > > provides the interface to the storage, i.e. non-volatile flash.
> > > > > 
> > > > > What about systems where the bootloader is part of the system and 
> > > > > users only have 
> > > > > the ability to provide kernel images, but no ability to change the 
> > > > > boot loader?
> > > > 
> > > > It depends on how the bootloader works. If the system uses my
> > > > implementation of shim loader, it surely has the ability to lower SV,
> > > > but it requires physical access on purpose.
> > > 
> > > And that's my problem: if in practice the bootloader is 'part of the 
> > > system', is 
> > > signed and is updated like the firmware, then putting a "Security 
> > > Version" into 
> > > the kernel image and architecting a boot protocol for a monotonic method 
> > > for the 
> > > bootloader to restrict the loading of kernel images is an obviously bad 
> > > idea.
> > > 
> > Even though the bootloader doesn't actually block the booting?
> 
> We don't know that for sure, in that scenario *how* the bootloader interprets 
> the 
> SV is not under the user's control...
> 
OK, it seems the implementation in shim brings up some concern. I'll
discuss with my colleagues for other possible solutions.

Cheers,

Gary Lin

Re: [RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub

[Alan Cox]

On Tue,  5 Dec 2017 18:01:46 +0800
Gary Lin  wrote:

> The series of patches introduce Security Version to EFI stub.
> 
> Security Version is a monotonically increasing number and designed to
> prevent the user from loading an insecure kernel accidentally. The
> bootloader maintains a list of security versions corresponding to
> different distributions. After fixing a critical vulnerability, the
> distribution kernel maintainer bumps the "version", and the bootloader
> updates the list automatically. 

This seems a mindbogglingly complicated way to implement something you
could do with a trivial script in the package that updates the list of
iffy kernels and when generating the new grub.conf puts them in a menu
of 'old insecure' kernels.

Why do you even need this in the EFI stub ?

What happens if you want to invalidate an old kernel but not push a new
one ? Today if you've got a package that maintains the list of 'iffy'
kernels you can push a tiny package, under your scheme you've got to push
new kernels which is an un-necessary and high risk OS change.

It just feels like an attempt to solve the problem in completely the
wrong place.

Alan

Re: [RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub

[Alan Cox]

On Tue,  5 Dec 2017 18:01:46 +0800
Gary Lin  wrote:

> The series of patches introduce Security Version to EFI stub.
> 
> Security Version is a monotonically increasing number and designed to
> prevent the user from loading an insecure kernel accidentally. The
> bootloader maintains a list of security versions corresponding to
> different distributions. After fixing a critical vulnerability, the
> distribution kernel maintainer bumps the "version", and the bootloader
> updates the list automatically. 

This seems a mindbogglingly complicated way to implement something you
could do with a trivial script in the package that updates the list of
iffy kernels and when generating the new grub.conf puts them in a menu
of 'old insecure' kernels.

Why do you even need this in the EFI stub ?

What happens if you want to invalidate an old kernel but not push a new
one ? Today if you've got a package that maintains the list of 'iffy'
kernels you can push a tiny package, under your scheme you've got to push
new kernels which is an un-necessary and high risk OS change.

It just feels like an attempt to solve the problem in completely the
wrong place.

Alan

Re: [RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub

[Ingo Molnar]

* Gary Lin  wrote:

> On Thu, Dec 07, 2017 at 09:18:16AM +0100, Ingo Molnar wrote:
> > 
> > * Gary Lin  wrote:
> > 
> > > On Thu, Dec 07, 2017 at 07:09:27AM +0100, Ingo Molnar wrote:
> > > > 
> > > > * Gary Lin  wrote:
> > > > 
> > > > > On Wed, Dec 06, 2017 at 07:37:34PM +0100, Ingo Molnar wrote:
> > > > > > 
> > > > > > * Gary Lin  wrote:
> > > > > > 
> > > > > > > On Tue, Dec 05, 2017 at 04:14:26PM -0500, Josh Boyer wrote:
> > > > > > > > On Tue, Dec 5, 2017 at 5:01 AM, Gary Lin  wrote:
> > > > > > > > > The series of patches introduce Security Version to EFI stub.
> > > > > > > > >
> > > > > > > > > Security Version is a monotonically increasing number and 
> > > > > > > > > designed to
> > > > > > > > > prevent the user from loading an insecure kernel 
> > > > > > > > > accidentally. The
> > > > > > > > > bootloader maintains a list of security versions 
> > > > > > > > > corresponding to
> > > > > > > > > different distributions. After fixing a critical 
> > > > > > > > > vulnerability, the
> > > > > > > > > distribution kernel maintainer bumps the "version", and the 
> > > > > > > > > bootloader
> > > > > > > > > updates the list automatically. When the user tries to load a 
> > > > > > > > > kernel
> > > > > > > > > with a lower security version, the bootloader shows a warning 
> > > > > > > > > prompt
> > > > > > > > > to notify the user the potential risk.
> > > > > > > > 
> > > > > > > > If a distribution releases a kernel with a higher security 
> > > > > > > > version and
> > > > > > > > that it automatically updated on boot, what happens if that 
> > > > > > > > kernel
> > > > > > > > contains a different bug that causes it to fail to boot or break
> > > > > > > > critical functionality?  At that point, the user's machine 
> > > > > > > > would be in
> > > > > > > > a state where the higher security version is enforced but the 
> > > > > > > > only
> > > > > > > > kernel that provides that is broken.  Wouldn't that make a bad
> > > > > > > > situation even worse by now requiring manual acceptance of the 
> > > > > > > > older
> > > > > > > > SV kernel boot physically at the machine?
> > > > > > > > 
> > > > > > > > I feel like I'm missing a detail here or something.
> > > > > > > > 
> > > > > > > If the new kernel fails to boot, then the user has to choose the 
> > > > > > > kernel
> > > > > > > manually anyway, and there will be an option in the warning 
> > > > > > > prompt to
> > > > > > > lower SV.
> > > > > > 
> > > > > > And what if the firmware does not support a lowering of the SV?
> > > > > > 
> > > > > The SV list is manipulated by the bootloader, and the firmware only
> > > > > provides the interface to the storage, i.e. non-volatile flash.
> > > > 
> > > > What about systems where the bootloader is part of the system and users 
> > > > only have 
> > > > the ability to provide kernel images, but no ability to change the boot 
> > > > loader?
> > > 
> > > It depends on how the bootloader works. If the system uses my
> > > implementation of shim loader, it surely has the ability to lower SV,
> > > but it requires physical access on purpose.
> > 
> > And that's my problem: if in practice the bootloader is 'part of the 
> > system', is 
> > signed and is updated like the firmware, then putting a "Security Version" 
> > into 
> > the kernel image and architecting a boot protocol for a monotonic method 
> > for the 
> > bootloader to restrict the loading of kernel images is an obviously bad 
> > idea.
> > 
> Even though the bootloader doesn't actually block the booting?

We don't know that for sure, in that scenario *how* the bootloader interprets 
the 
SV is not under the user's control...

Thanks,

Ingo

Re: [RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub

[Ingo Molnar]

* Gary Lin  wrote:

> On Thu, Dec 07, 2017 at 09:18:16AM +0100, Ingo Molnar wrote:
> > 
> > * Gary Lin  wrote:
> > 
> > > On Thu, Dec 07, 2017 at 07:09:27AM +0100, Ingo Molnar wrote:
> > > > 
> > > > * Gary Lin  wrote:
> > > > 
> > > > > On Wed, Dec 06, 2017 at 07:37:34PM +0100, Ingo Molnar wrote:
> > > > > > 
> > > > > > * Gary Lin  wrote:
> > > > > > 
> > > > > > > On Tue, Dec 05, 2017 at 04:14:26PM -0500, Josh Boyer wrote:
> > > > > > > > On Tue, Dec 5, 2017 at 5:01 AM, Gary Lin  wrote:
> > > > > > > > > The series of patches introduce Security Version to EFI stub.
> > > > > > > > >
> > > > > > > > > Security Version is a monotonically increasing number and 
> > > > > > > > > designed to
> > > > > > > > > prevent the user from loading an insecure kernel 
> > > > > > > > > accidentally. The
> > > > > > > > > bootloader maintains a list of security versions 
> > > > > > > > > corresponding to
> > > > > > > > > different distributions. After fixing a critical 
> > > > > > > > > vulnerability, the
> > > > > > > > > distribution kernel maintainer bumps the "version", and the 
> > > > > > > > > bootloader
> > > > > > > > > updates the list automatically. When the user tries to load a 
> > > > > > > > > kernel
> > > > > > > > > with a lower security version, the bootloader shows a warning 
> > > > > > > > > prompt
> > > > > > > > > to notify the user the potential risk.
> > > > > > > > 
> > > > > > > > If a distribution releases a kernel with a higher security 
> > > > > > > > version and
> > > > > > > > that it automatically updated on boot, what happens if that 
> > > > > > > > kernel
> > > > > > > > contains a different bug that causes it to fail to boot or break
> > > > > > > > critical functionality?  At that point, the user's machine 
> > > > > > > > would be in
> > > > > > > > a state where the higher security version is enforced but the 
> > > > > > > > only
> > > > > > > > kernel that provides that is broken.  Wouldn't that make a bad
> > > > > > > > situation even worse by now requiring manual acceptance of the 
> > > > > > > > older
> > > > > > > > SV kernel boot physically at the machine?
> > > > > > > > 
> > > > > > > > I feel like I'm missing a detail here or something.
> > > > > > > > 
> > > > > > > If the new kernel fails to boot, then the user has to choose the 
> > > > > > > kernel
> > > > > > > manually anyway, and there will be an option in the warning 
> > > > > > > prompt to
> > > > > > > lower SV.
> > > > > > 
> > > > > > And what if the firmware does not support a lowering of the SV?
> > > > > > 
> > > > > The SV list is manipulated by the bootloader, and the firmware only
> > > > > provides the interface to the storage, i.e. non-volatile flash.
> > > > 
> > > > What about systems where the bootloader is part of the system and users 
> > > > only have 
> > > > the ability to provide kernel images, but no ability to change the boot 
> > > > loader?
> > > 
> > > It depends on how the bootloader works. If the system uses my
> > > implementation of shim loader, it surely has the ability to lower SV,
> > > but it requires physical access on purpose.
> > 
> > And that's my problem: if in practice the bootloader is 'part of the 
> > system', is 
> > signed and is updated like the firmware, then putting a "Security Version" 
> > into 
> > the kernel image and architecting a boot protocol for a monotonic method 
> > for the 
> > bootloader to restrict the loading of kernel images is an obviously bad 
> > idea.
> > 
> Even though the bootloader doesn't actually block the booting?

We don't know that for sure, in that scenario *how* the bootloader interprets 
the 
SV is not under the user's control...

Thanks,

Ingo

Re: [RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub

[Gary Lin]

On Thu, Dec 07, 2017 at 09:18:16AM +0100, Ingo Molnar wrote:
> 
> * Gary Lin  wrote:
> 
> > On Thu, Dec 07, 2017 at 07:09:27AM +0100, Ingo Molnar wrote:
> > > 
> > > * Gary Lin  wrote:
> > > 
> > > > On Wed, Dec 06, 2017 at 07:37:34PM +0100, Ingo Molnar wrote:
> > > > > 
> > > > > * Gary Lin  wrote:
> > > > > 
> > > > > > On Tue, Dec 05, 2017 at 04:14:26PM -0500, Josh Boyer wrote:
> > > > > > > On Tue, Dec 5, 2017 at 5:01 AM, Gary Lin  wrote:
> > > > > > > > The series of patches introduce Security Version to EFI stub.
> > > > > > > >
> > > > > > > > Security Version is a monotonically increasing number and 
> > > > > > > > designed to
> > > > > > > > prevent the user from loading an insecure kernel accidentally. 
> > > > > > > > The
> > > > > > > > bootloader maintains a list of security versions corresponding 
> > > > > > > > to
> > > > > > > > different distributions. After fixing a critical vulnerability, 
> > > > > > > > the
> > > > > > > > distribution kernel maintainer bumps the "version", and the 
> > > > > > > > bootloader
> > > > > > > > updates the list automatically. When the user tries to load a 
> > > > > > > > kernel
> > > > > > > > with a lower security version, the bootloader shows a warning 
> > > > > > > > prompt
> > > > > > > > to notify the user the potential risk.
> > > > > > > 
> > > > > > > If a distribution releases a kernel with a higher security 
> > > > > > > version and
> > > > > > > that it automatically updated on boot, what happens if that kernel
> > > > > > > contains a different bug that causes it to fail to boot or break
> > > > > > > critical functionality?  At that point, the user's machine would 
> > > > > > > be in
> > > > > > > a state where the higher security version is enforced but the only
> > > > > > > kernel that provides that is broken.  Wouldn't that make a bad
> > > > > > > situation even worse by now requiring manual acceptance of the 
> > > > > > > older
> > > > > > > SV kernel boot physically at the machine?
> > > > > > > 
> > > > > > > I feel like I'm missing a detail here or something.
> > > > > > > 
> > > > > > If the new kernel fails to boot, then the user has to choose the 
> > > > > > kernel
> > > > > > manually anyway, and there will be an option in the warning prompt 
> > > > > > to
> > > > > > lower SV.
> > > > > 
> > > > > And what if the firmware does not support a lowering of the SV?
> > > > > 
> > > > The SV list is manipulated by the bootloader, and the firmware only
> > > > provides the interface to the storage, i.e. non-volatile flash.
> > > 
> > > What about systems where the bootloader is part of the system and users 
> > > only have 
> > > the ability to provide kernel images, but no ability to change the boot 
> > > loader?
> > 
> > It depends on how the bootloader works. If the system uses my
> > implementation of shim loader, it surely has the ability to lower SV,
> > but it requires physical access on purpose.
> 
> And that's my problem: if in practice the bootloader is 'part of the system', 
> is 
> signed and is updated like the firmware, then putting a "Security Version" 
> into 
> the kernel image and architecting a boot protocol for a monotonic method for 
> the 
> bootloader to restrict the loading of kernel images is an obviously bad idea.
> 
Even though the bootloader doesn't actually block the booting?

If the bootloader loads a kernel with lower SV, by default, the warning
prompt lasts for 30 seconds, and the system continues booting if the
user doesn't intervene. For the paranoid user, a variable can be set to
make the bootloader wait forever. Is it acceptable?

Thanks,

Gary Lin

Re: [RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub

[Gary Lin]

On Thu, Dec 07, 2017 at 09:18:16AM +0100, Ingo Molnar wrote:
> 
> * Gary Lin  wrote:
> 
> > On Thu, Dec 07, 2017 at 07:09:27AM +0100, Ingo Molnar wrote:
> > > 
> > > * Gary Lin  wrote:
> > > 
> > > > On Wed, Dec 06, 2017 at 07:37:34PM +0100, Ingo Molnar wrote:
> > > > > 
> > > > > * Gary Lin  wrote:
> > > > > 
> > > > > > On Tue, Dec 05, 2017 at 04:14:26PM -0500, Josh Boyer wrote:
> > > > > > > On Tue, Dec 5, 2017 at 5:01 AM, Gary Lin  wrote:
> > > > > > > > The series of patches introduce Security Version to EFI stub.
> > > > > > > >
> > > > > > > > Security Version is a monotonically increasing number and 
> > > > > > > > designed to
> > > > > > > > prevent the user from loading an insecure kernel accidentally. 
> > > > > > > > The
> > > > > > > > bootloader maintains a list of security versions corresponding 
> > > > > > > > to
> > > > > > > > different distributions. After fixing a critical vulnerability, 
> > > > > > > > the
> > > > > > > > distribution kernel maintainer bumps the "version", and the 
> > > > > > > > bootloader
> > > > > > > > updates the list automatically. When the user tries to load a 
> > > > > > > > kernel
> > > > > > > > with a lower security version, the bootloader shows a warning 
> > > > > > > > prompt
> > > > > > > > to notify the user the potential risk.
> > > > > > > 
> > > > > > > If a distribution releases a kernel with a higher security 
> > > > > > > version and
> > > > > > > that it automatically updated on boot, what happens if that kernel
> > > > > > > contains a different bug that causes it to fail to boot or break
> > > > > > > critical functionality?  At that point, the user's machine would 
> > > > > > > be in
> > > > > > > a state where the higher security version is enforced but the only
> > > > > > > kernel that provides that is broken.  Wouldn't that make a bad
> > > > > > > situation even worse by now requiring manual acceptance of the 
> > > > > > > older
> > > > > > > SV kernel boot physically at the machine?
> > > > > > > 
> > > > > > > I feel like I'm missing a detail here or something.
> > > > > > > 
> > > > > > If the new kernel fails to boot, then the user has to choose the 
> > > > > > kernel
> > > > > > manually anyway, and there will be an option in the warning prompt 
> > > > > > to
> > > > > > lower SV.
> > > > > 
> > > > > And what if the firmware does not support a lowering of the SV?
> > > > > 
> > > > The SV list is manipulated by the bootloader, and the firmware only
> > > > provides the interface to the storage, i.e. non-volatile flash.
> > > 
> > > What about systems where the bootloader is part of the system and users 
> > > only have 
> > > the ability to provide kernel images, but no ability to change the boot 
> > > loader?
> > 
> > It depends on how the bootloader works. If the system uses my
> > implementation of shim loader, it surely has the ability to lower SV,
> > but it requires physical access on purpose.
> 
> And that's my problem: if in practice the bootloader is 'part of the system', 
> is 
> signed and is updated like the firmware, then putting a "Security Version" 
> into 
> the kernel image and architecting a boot protocol for a monotonic method for 
> the 
> bootloader to restrict the loading of kernel images is an obviously bad idea.
> 
Even though the bootloader doesn't actually block the booting?

If the bootloader loads a kernel with lower SV, by default, the warning
prompt lasts for 30 seconds, and the system continues booting if the
user doesn't intervene. For the paranoid user, a variable can be set to
make the bootloader wait forever. Is it acceptable?

Thanks,

Gary Lin

Re: [RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub

[Ingo Molnar]

* Gary Lin  wrote:

> On Thu, Dec 07, 2017 at 07:09:27AM +0100, Ingo Molnar wrote:
> > 
> > * Gary Lin  wrote:
> > 
> > > On Wed, Dec 06, 2017 at 07:37:34PM +0100, Ingo Molnar wrote:
> > > > 
> > > > * Gary Lin  wrote:
> > > > 
> > > > > On Tue, Dec 05, 2017 at 04:14:26PM -0500, Josh Boyer wrote:
> > > > > > On Tue, Dec 5, 2017 at 5:01 AM, Gary Lin  wrote:
> > > > > > > The series of patches introduce Security Version to EFI stub.
> > > > > > >
> > > > > > > Security Version is a monotonically increasing number and 
> > > > > > > designed to
> > > > > > > prevent the user from loading an insecure kernel accidentally. The
> > > > > > > bootloader maintains a list of security versions corresponding to
> > > > > > > different distributions. After fixing a critical vulnerability, 
> > > > > > > the
> > > > > > > distribution kernel maintainer bumps the "version", and the 
> > > > > > > bootloader
> > > > > > > updates the list automatically. When the user tries to load a 
> > > > > > > kernel
> > > > > > > with a lower security version, the bootloader shows a warning 
> > > > > > > prompt
> > > > > > > to notify the user the potential risk.
> > > > > > 
> > > > > > If a distribution releases a kernel with a higher security version 
> > > > > > and
> > > > > > that it automatically updated on boot, what happens if that kernel
> > > > > > contains a different bug that causes it to fail to boot or break
> > > > > > critical functionality?  At that point, the user's machine would be 
> > > > > > in
> > > > > > a state where the higher security version is enforced but the only
> > > > > > kernel that provides that is broken.  Wouldn't that make a bad
> > > > > > situation even worse by now requiring manual acceptance of the older
> > > > > > SV kernel boot physically at the machine?
> > > > > > 
> > > > > > I feel like I'm missing a detail here or something.
> > > > > > 
> > > > > If the new kernel fails to boot, then the user has to choose the 
> > > > > kernel
> > > > > manually anyway, and there will be an option in the warning prompt to
> > > > > lower SV.
> > > > 
> > > > And what if the firmware does not support a lowering of the SV?
> > > > 
> > > The SV list is manipulated by the bootloader, and the firmware only
> > > provides the interface to the storage, i.e. non-volatile flash.
> > 
> > What about systems where the bootloader is part of the system and users 
> > only have 
> > the ability to provide kernel images, but no ability to change the boot 
> > loader?
> 
> It depends on how the bootloader works. If the system uses my
> implementation of shim loader, it surely has the ability to lower SV,
> but it requires physical access on purpose.

And that's my problem: if in practice the bootloader is 'part of the system', 
is 
signed and is updated like the firmware, then putting a "Security Version" into 
the kernel image and architecting a boot protocol for a monotonic method for 
the 
bootloader to restrict the loading of kernel images is an obviously bad idea.

Thanks,

Ingo

Re: [RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub

[Ingo Molnar]

* Gary Lin  wrote:

> On Thu, Dec 07, 2017 at 07:09:27AM +0100, Ingo Molnar wrote:
> > 
> > * Gary Lin  wrote:
> > 
> > > On Wed, Dec 06, 2017 at 07:37:34PM +0100, Ingo Molnar wrote:
> > > > 
> > > > * Gary Lin  wrote:
> > > > 
> > > > > On Tue, Dec 05, 2017 at 04:14:26PM -0500, Josh Boyer wrote:
> > > > > > On Tue, Dec 5, 2017 at 5:01 AM, Gary Lin  wrote:
> > > > > > > The series of patches introduce Security Version to EFI stub.
> > > > > > >
> > > > > > > Security Version is a monotonically increasing number and 
> > > > > > > designed to
> > > > > > > prevent the user from loading an insecure kernel accidentally. The
> > > > > > > bootloader maintains a list of security versions corresponding to
> > > > > > > different distributions. After fixing a critical vulnerability, 
> > > > > > > the
> > > > > > > distribution kernel maintainer bumps the "version", and the 
> > > > > > > bootloader
> > > > > > > updates the list automatically. When the user tries to load a 
> > > > > > > kernel
> > > > > > > with a lower security version, the bootloader shows a warning 
> > > > > > > prompt
> > > > > > > to notify the user the potential risk.
> > > > > > 
> > > > > > If a distribution releases a kernel with a higher security version 
> > > > > > and
> > > > > > that it automatically updated on boot, what happens if that kernel
> > > > > > contains a different bug that causes it to fail to boot or break
> > > > > > critical functionality?  At that point, the user's machine would be 
> > > > > > in
> > > > > > a state where the higher security version is enforced but the only
> > > > > > kernel that provides that is broken.  Wouldn't that make a bad
> > > > > > situation even worse by now requiring manual acceptance of the older
> > > > > > SV kernel boot physically at the machine?
> > > > > > 
> > > > > > I feel like I'm missing a detail here or something.
> > > > > > 
> > > > > If the new kernel fails to boot, then the user has to choose the 
> > > > > kernel
> > > > > manually anyway, and there will be an option in the warning prompt to
> > > > > lower SV.
> > > > 
> > > > And what if the firmware does not support a lowering of the SV?
> > > > 
> > > The SV list is manipulated by the bootloader, and the firmware only
> > > provides the interface to the storage, i.e. non-volatile flash.
> > 
> > What about systems where the bootloader is part of the system and users 
> > only have 
> > the ability to provide kernel images, but no ability to change the boot 
> > loader?
> 
> It depends on how the bootloader works. If the system uses my
> implementation of shim loader, it surely has the ability to lower SV,
> but it requires physical access on purpose.

And that's my problem: if in practice the bootloader is 'part of the system', 
is 
signed and is updated like the firmware, then putting a "Security Version" into 
the kernel image and architecting a boot protocol for a monotonic method for 
the 
bootloader to restrict the loading of kernel images is an obviously bad idea.

Thanks,

Ingo

Re: [RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub

[Gary Lin]

On Thu, Dec 07, 2017 at 07:09:27AM +0100, Ingo Molnar wrote:
> 
> * Gary Lin  wrote:
> 
> > On Wed, Dec 06, 2017 at 07:37:34PM +0100, Ingo Molnar wrote:
> > > 
> > > * Gary Lin  wrote:
> > > 
> > > > On Tue, Dec 05, 2017 at 04:14:26PM -0500, Josh Boyer wrote:
> > > > > On Tue, Dec 5, 2017 at 5:01 AM, Gary Lin  wrote:
> > > > > > The series of patches introduce Security Version to EFI stub.
> > > > > >
> > > > > > Security Version is a monotonically increasing number and designed 
> > > > > > to
> > > > > > prevent the user from loading an insecure kernel accidentally. The
> > > > > > bootloader maintains a list of security versions corresponding to
> > > > > > different distributions. After fixing a critical vulnerability, the
> > > > > > distribution kernel maintainer bumps the "version", and the 
> > > > > > bootloader
> > > > > > updates the list automatically. When the user tries to load a kernel
> > > > > > with a lower security version, the bootloader shows a warning prompt
> > > > > > to notify the user the potential risk.
> > > > > 
> > > > > If a distribution releases a kernel with a higher security version and
> > > > > that it automatically updated on boot, what happens if that kernel
> > > > > contains a different bug that causes it to fail to boot or break
> > > > > critical functionality?  At that point, the user's machine would be in
> > > > > a state where the higher security version is enforced but the only
> > > > > kernel that provides that is broken.  Wouldn't that make a bad
> > > > > situation even worse by now requiring manual acceptance of the older
> > > > > SV kernel boot physically at the machine?
> > > > > 
> > > > > I feel like I'm missing a detail here or something.
> > > > > 
> > > > If the new kernel fails to boot, then the user has to choose the kernel
> > > > manually anyway, and there will be an option in the warning prompt to
> > > > lower SV.
> > > 
> > > And what if the firmware does not support a lowering of the SV?
> > > 
> > The SV list is manipulated by the bootloader, and the firmware only
> > provides the interface to the storage, i.e. non-volatile flash.
> 
> What about systems where the bootloader is part of the system and users only 
> have 
> the ability to provide kernel images, but no ability to change the boot 
> loader?
> 
It depends on how the bootloader works. If the system uses my
implementation of shim loader, it surely has the ability to lower SV,
but it requires physical access on purpose.

The Security Version check is a warning rather than a hard block like the
signature check. The current plan is to add an extra check in the shim
verify protocol, so that we can check SV right after the signature check.
I'm thinking about adding a UEFI variable to control the timeout of the
warning prompt, e.g. 30 for 30 seconds and 0 for waiting indefinitely,
so that the warning prompt won't block the system boot unless the system
administrator wants so.

As for other bootloaders, SV is just a few extra bytes in the kernel
image and means nothing to them.

Cheers,

Gary Lin

Re: [RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub

[Gary Lin]

On Thu, Dec 07, 2017 at 07:09:27AM +0100, Ingo Molnar wrote:
> 
> * Gary Lin  wrote:
> 
> > On Wed, Dec 06, 2017 at 07:37:34PM +0100, Ingo Molnar wrote:
> > > 
> > > * Gary Lin  wrote:
> > > 
> > > > On Tue, Dec 05, 2017 at 04:14:26PM -0500, Josh Boyer wrote:
> > > > > On Tue, Dec 5, 2017 at 5:01 AM, Gary Lin  wrote:
> > > > > > The series of patches introduce Security Version to EFI stub.
> > > > > >
> > > > > > Security Version is a monotonically increasing number and designed 
> > > > > > to
> > > > > > prevent the user from loading an insecure kernel accidentally. The
> > > > > > bootloader maintains a list of security versions corresponding to
> > > > > > different distributions. After fixing a critical vulnerability, the
> > > > > > distribution kernel maintainer bumps the "version", and the 
> > > > > > bootloader
> > > > > > updates the list automatically. When the user tries to load a kernel
> > > > > > with a lower security version, the bootloader shows a warning prompt
> > > > > > to notify the user the potential risk.
> > > > > 
> > > > > If a distribution releases a kernel with a higher security version and
> > > > > that it automatically updated on boot, what happens if that kernel
> > > > > contains a different bug that causes it to fail to boot or break
> > > > > critical functionality?  At that point, the user's machine would be in
> > > > > a state where the higher security version is enforced but the only
> > > > > kernel that provides that is broken.  Wouldn't that make a bad
> > > > > situation even worse by now requiring manual acceptance of the older
> > > > > SV kernel boot physically at the machine?
> > > > > 
> > > > > I feel like I'm missing a detail here or something.
> > > > > 
> > > > If the new kernel fails to boot, then the user has to choose the kernel
> > > > manually anyway, and there will be an option in the warning prompt to
> > > > lower SV.
> > > 
> > > And what if the firmware does not support a lowering of the SV?
> > > 
> > The SV list is manipulated by the bootloader, and the firmware only
> > provides the interface to the storage, i.e. non-volatile flash.
> 
> What about systems where the bootloader is part of the system and users only 
> have 
> the ability to provide kernel images, but no ability to change the boot 
> loader?
> 
It depends on how the bootloader works. If the system uses my
implementation of shim loader, it surely has the ability to lower SV,
but it requires physical access on purpose.

The Security Version check is a warning rather than a hard block like the
signature check. The current plan is to add an extra check in the shim
verify protocol, so that we can check SV right after the signature check.
I'm thinking about adding a UEFI variable to control the timeout of the
warning prompt, e.g. 30 for 30 seconds and 0 for waiting indefinitely,
so that the warning prompt won't block the system boot unless the system
administrator wants so.

As for other bootloaders, SV is just a few extra bytes in the kernel
image and means nothing to them.

Cheers,

Gary Lin

Re: [RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub

[Ingo Molnar]

* Gary Lin  wrote:

> On Wed, Dec 06, 2017 at 07:37:34PM +0100, Ingo Molnar wrote:
> > 
> > * Gary Lin  wrote:
> > 
> > > On Tue, Dec 05, 2017 at 04:14:26PM -0500, Josh Boyer wrote:
> > > > On Tue, Dec 5, 2017 at 5:01 AM, Gary Lin  wrote:
> > > > > The series of patches introduce Security Version to EFI stub.
> > > > >
> > > > > Security Version is a monotonically increasing number and designed to
> > > > > prevent the user from loading an insecure kernel accidentally. The
> > > > > bootloader maintains a list of security versions corresponding to
> > > > > different distributions. After fixing a critical vulnerability, the
> > > > > distribution kernel maintainer bumps the "version", and the bootloader
> > > > > updates the list automatically. When the user tries to load a kernel
> > > > > with a lower security version, the bootloader shows a warning prompt
> > > > > to notify the user the potential risk.
> > > > 
> > > > If a distribution releases a kernel with a higher security version and
> > > > that it automatically updated on boot, what happens if that kernel
> > > > contains a different bug that causes it to fail to boot or break
> > > > critical functionality?  At that point, the user's machine would be in
> > > > a state where the higher security version is enforced but the only
> > > > kernel that provides that is broken.  Wouldn't that make a bad
> > > > situation even worse by now requiring manual acceptance of the older
> > > > SV kernel boot physically at the machine?
> > > > 
> > > > I feel like I'm missing a detail here or something.
> > > > 
> > > If the new kernel fails to boot, then the user has to choose the kernel
> > > manually anyway, and there will be an option in the warning prompt to
> > > lower SV.
> > 
> > And what if the firmware does not support a lowering of the SV?
> > 
> The SV list is manipulated by the bootloader, and the firmware only
> provides the interface to the storage, i.e. non-volatile flash.

What about systems where the bootloader is part of the system and users only 
have 
the ability to provide kernel images, but no ability to change the boot loader?

Thanks,

Ingo

Re: [RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub

[Ingo Molnar]

* Gary Lin  wrote:

> On Wed, Dec 06, 2017 at 07:37:34PM +0100, Ingo Molnar wrote:
> > 
> > * Gary Lin  wrote:
> > 
> > > On Tue, Dec 05, 2017 at 04:14:26PM -0500, Josh Boyer wrote:
> > > > On Tue, Dec 5, 2017 at 5:01 AM, Gary Lin  wrote:
> > > > > The series of patches introduce Security Version to EFI stub.
> > > > >
> > > > > Security Version is a monotonically increasing number and designed to
> > > > > prevent the user from loading an insecure kernel accidentally. The
> > > > > bootloader maintains a list of security versions corresponding to
> > > > > different distributions. After fixing a critical vulnerability, the
> > > > > distribution kernel maintainer bumps the "version", and the bootloader
> > > > > updates the list automatically. When the user tries to load a kernel
> > > > > with a lower security version, the bootloader shows a warning prompt
> > > > > to notify the user the potential risk.
> > > > 
> > > > If a distribution releases a kernel with a higher security version and
> > > > that it automatically updated on boot, what happens if that kernel
> > > > contains a different bug that causes it to fail to boot or break
> > > > critical functionality?  At that point, the user's machine would be in
> > > > a state where the higher security version is enforced but the only
> > > > kernel that provides that is broken.  Wouldn't that make a bad
> > > > situation even worse by now requiring manual acceptance of the older
> > > > SV kernel boot physically at the machine?
> > > > 
> > > > I feel like I'm missing a detail here or something.
> > > > 
> > > If the new kernel fails to boot, then the user has to choose the kernel
> > > manually anyway, and there will be an option in the warning prompt to
> > > lower SV.
> > 
> > And what if the firmware does not support a lowering of the SV?
> > 
> The SV list is manipulated by the bootloader, and the firmware only
> provides the interface to the storage, i.e. non-volatile flash.

What about systems where the bootloader is part of the system and users only 
have 
the ability to provide kernel images, but no ability to change the boot loader?

Thanks,

Ingo

Re: [RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub

[Gary Lin]

On Wed, Dec 06, 2017 at 07:37:34PM +0100, Ingo Molnar wrote:
> 
> * Gary Lin  wrote:
> 
> > On Tue, Dec 05, 2017 at 04:14:26PM -0500, Josh Boyer wrote:
> > > On Tue, Dec 5, 2017 at 5:01 AM, Gary Lin  wrote:
> > > > The series of patches introduce Security Version to EFI stub.
> > > >
> > > > Security Version is a monotonically increasing number and designed to
> > > > prevent the user from loading an insecure kernel accidentally. The
> > > > bootloader maintains a list of security versions corresponding to
> > > > different distributions. After fixing a critical vulnerability, the
> > > > distribution kernel maintainer bumps the "version", and the bootloader
> > > > updates the list automatically. When the user tries to load a kernel
> > > > with a lower security version, the bootloader shows a warning prompt
> > > > to notify the user the potential risk.
> > > 
> > > If a distribution releases a kernel with a higher security version and
> > > that it automatically updated on boot, what happens if that kernel
> > > contains a different bug that causes it to fail to boot or break
> > > critical functionality?  At that point, the user's machine would be in
> > > a state where the higher security version is enforced but the only
> > > kernel that provides that is broken.  Wouldn't that make a bad
> > > situation even worse by now requiring manual acceptance of the older
> > > SV kernel boot physically at the machine?
> > > 
> > > I feel like I'm missing a detail here or something.
> > > 
> > If the new kernel fails to boot, then the user has to choose the kernel
> > manually anyway, and there will be an option in the warning prompt to
> > lower SV.
> 
> And what if the firmware does not support a lowering of the SV?
> 
The SV list is manipulated by the bootloader, and the firmware only
provides the interface to the storage, i.e. non-volatile flash.

Cheers,

Gary Lin

Re: [RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub

[Gary Lin]

On Wed, Dec 06, 2017 at 07:37:34PM +0100, Ingo Molnar wrote:
> 
> * Gary Lin  wrote:
> 
> > On Tue, Dec 05, 2017 at 04:14:26PM -0500, Josh Boyer wrote:
> > > On Tue, Dec 5, 2017 at 5:01 AM, Gary Lin  wrote:
> > > > The series of patches introduce Security Version to EFI stub.
> > > >
> > > > Security Version is a monotonically increasing number and designed to
> > > > prevent the user from loading an insecure kernel accidentally. The
> > > > bootloader maintains a list of security versions corresponding to
> > > > different distributions. After fixing a critical vulnerability, the
> > > > distribution kernel maintainer bumps the "version", and the bootloader
> > > > updates the list automatically. When the user tries to load a kernel
> > > > with a lower security version, the bootloader shows a warning prompt
> > > > to notify the user the potential risk.
> > > 
> > > If a distribution releases a kernel with a higher security version and
> > > that it automatically updated on boot, what happens if that kernel
> > > contains a different bug that causes it to fail to boot or break
> > > critical functionality?  At that point, the user's machine would be in
> > > a state where the higher security version is enforced but the only
> > > kernel that provides that is broken.  Wouldn't that make a bad
> > > situation even worse by now requiring manual acceptance of the older
> > > SV kernel boot physically at the machine?
> > > 
> > > I feel like I'm missing a detail here or something.
> > > 
> > If the new kernel fails to boot, then the user has to choose the kernel
> > manually anyway, and there will be an option in the warning prompt to
> > lower SV.
> 
> And what if the firmware does not support a lowering of the SV?
> 
The SV list is manipulated by the bootloader, and the firmware only
provides the interface to the storage, i.e. non-volatile flash.

Cheers,

Gary Lin

Re: [RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub

[Ingo Molnar]

* Gary Lin  wrote:

> On Tue, Dec 05, 2017 at 04:14:26PM -0500, Josh Boyer wrote:
> > On Tue, Dec 5, 2017 at 5:01 AM, Gary Lin  wrote:
> > > The series of patches introduce Security Version to EFI stub.
> > >
> > > Security Version is a monotonically increasing number and designed to
> > > prevent the user from loading an insecure kernel accidentally. The
> > > bootloader maintains a list of security versions corresponding to
> > > different distributions. After fixing a critical vulnerability, the
> > > distribution kernel maintainer bumps the "version", and the bootloader
> > > updates the list automatically. When the user tries to load a kernel
> > > with a lower security version, the bootloader shows a warning prompt
> > > to notify the user the potential risk.
> > 
> > If a distribution releases a kernel with a higher security version and
> > that it automatically updated on boot, what happens if that kernel
> > contains a different bug that causes it to fail to boot or break
> > critical functionality?  At that point, the user's machine would be in
> > a state where the higher security version is enforced but the only
> > kernel that provides that is broken.  Wouldn't that make a bad
> > situation even worse by now requiring manual acceptance of the older
> > SV kernel boot physically at the machine?
> > 
> > I feel like I'm missing a detail here or something.
> > 
> If the new kernel fails to boot, then the user has to choose the kernel
> manually anyway, and there will be an option in the warning prompt to
> lower SV.

And what if the firmware does not support a lowering of the SV?

Thanks,

Ingo

Re: [RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub

[Ingo Molnar]

* Gary Lin  wrote:

> On Tue, Dec 05, 2017 at 04:14:26PM -0500, Josh Boyer wrote:
> > On Tue, Dec 5, 2017 at 5:01 AM, Gary Lin  wrote:
> > > The series of patches introduce Security Version to EFI stub.
> > >
> > > Security Version is a monotonically increasing number and designed to
> > > prevent the user from loading an insecure kernel accidentally. The
> > > bootloader maintains a list of security versions corresponding to
> > > different distributions. After fixing a critical vulnerability, the
> > > distribution kernel maintainer bumps the "version", and the bootloader
> > > updates the list automatically. When the user tries to load a kernel
> > > with a lower security version, the bootloader shows a warning prompt
> > > to notify the user the potential risk.
> > 
> > If a distribution releases a kernel with a higher security version and
> > that it automatically updated on boot, what happens if that kernel
> > contains a different bug that causes it to fail to boot or break
> > critical functionality?  At that point, the user's machine would be in
> > a state where the higher security version is enforced but the only
> > kernel that provides that is broken.  Wouldn't that make a bad
> > situation even worse by now requiring manual acceptance of the older
> > SV kernel boot physically at the machine?
> > 
> > I feel like I'm missing a detail here or something.
> > 
> If the new kernel fails to boot, then the user has to choose the kernel
> manually anyway, and there will be an option in the warning prompt to
> lower SV.

And what if the firmware does not support a lowering of the SV?

Thanks,

Ingo

Re: [RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub

[Gary Lin]

On Tue, Dec 05, 2017 at 04:14:26PM -0500, Josh Boyer wrote:
> On Tue, Dec 5, 2017 at 5:01 AM, Gary Lin  wrote:
> > The series of patches introduce Security Version to EFI stub.
> >
> > Security Version is a monotonically increasing number and designed to
> > prevent the user from loading an insecure kernel accidentally. The
> > bootloader maintains a list of security versions corresponding to
> > different distributions. After fixing a critical vulnerability, the
> > distribution kernel maintainer bumps the "version", and the bootloader
> > updates the list automatically. When the user tries to load a kernel
> > with a lower security version, the bootloader shows a warning prompt
> > to notify the user the potential risk.
> 
> If a distribution releases a kernel with a higher security version and
> that it automatically updated on boot, what happens if that kernel
> contains a different bug that causes it to fail to boot or break
> critical functionality?  At that point, the user's machine would be in
> a state where the higher security version is enforced but the only
> kernel that provides that is broken.  Wouldn't that make a bad
> situation even worse by now requiring manual acceptance of the older
> SV kernel boot physically at the machine?
> 
> I feel like I'm missing a detail here or something.
> 
If the new kernel fails to boot, then the user has to choose the kernel
manually anyway, and there will be an option in the warning prompt to
lower SV.

Since Security Version is meant to be a warning, not a hard block, we
can introduce a timeout to the warning prompt if necessary. The system
still boots, but with a longer boot time.

Gary Lin

> josh
> 
> > For more details: https://github.com/lcp/shim/wiki/Security-Version
> >
> > The original idea is to add a new PE/COFF section to store the data.
> > However, there are some restrictions.
> >
> > 1. For x86, the size limit of the EFI header is 0x200, and a section entry
> >in the section table takes 40 bytes. Currently, the EFI header already
> >occupies the first 0x1da bytes, so there is no room for a new section
> >entry.
> >
> > 2. The MemoryAttributes table sets the attributes of memory pages according
> >to the section flags. For ARM64, the minimal granularity is 4KB, but
> >Security Version only needs a few bytes, and it's pointless to allocate
> >4KB for it.
> >
> > Fortunately, there is a special section defined in PE/COFF: resource
> > section. The only known user of the resource section in UEFI is the HII
> > protocol which fetches data from "HII" directory. For Security Version, a
> > new directory called "LinuxSV" is created and it contains the file offset
> > to the struct of Security Version. The bootloader just follows the
> > resource table to fetch the "version" from the image file.
> >
> > v3:
> > - Move everything to the resource section to be compatible with both
> >   x86 and ARM64
> > v2:
> > - Decrease the size of secdata_offset to 2 bytes since the setup header
> >   is limited to around 32KB.
> > - Restructure the secdata section. The signer is now a null-terminated
> >   string. The type of distro_version changes to u32 in case the distro
> >   uses a long version.
> > - Modify the Kconfig names and add help.
> > - Remove the signer name hack in build.c.
> >
> > Cc: "H. Peter Anvin" 
> > Cc: Thomas Gleixner 
> > Cc: Ard Biesheuvel 
> > Cc: Ingo Molnar 
> > Cc: Matt Fleming 
> > Cc: Catalin Marinas 
> > Cc: Will Deacon 
> > Cc: Joey Lee 
> > Signed-off-by: Gary Lin 
> >
> > Gary Lin (2):
> >   x86/efi: Introduce Security Version to x86
> >   arm64/efi: Introduce Security Version to ARM64
> >
> >  arch/arm64/kernel/efi-header.S | 57 
> > ++
> >  arch/x86/boot/header.S | 55 
> > 
> >  drivers/firmware/efi/Kconfig   | 40 +
> >  3 files changed, 152 insertions(+)
> >
> > --
> > 2.15.0
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-efi" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub

[Gary Lin]

On Tue, Dec 05, 2017 at 04:14:26PM -0500, Josh Boyer wrote:
> On Tue, Dec 5, 2017 at 5:01 AM, Gary Lin  wrote:
> > The series of patches introduce Security Version to EFI stub.
> >
> > Security Version is a monotonically increasing number and designed to
> > prevent the user from loading an insecure kernel accidentally. The
> > bootloader maintains a list of security versions corresponding to
> > different distributions. After fixing a critical vulnerability, the
> > distribution kernel maintainer bumps the "version", and the bootloader
> > updates the list automatically. When the user tries to load a kernel
> > with a lower security version, the bootloader shows a warning prompt
> > to notify the user the potential risk.
> 
> If a distribution releases a kernel with a higher security version and
> that it automatically updated on boot, what happens if that kernel
> contains a different bug that causes it to fail to boot or break
> critical functionality?  At that point, the user's machine would be in
> a state where the higher security version is enforced but the only
> kernel that provides that is broken.  Wouldn't that make a bad
> situation even worse by now requiring manual acceptance of the older
> SV kernel boot physically at the machine?
> 
> I feel like I'm missing a detail here or something.
> 
If the new kernel fails to boot, then the user has to choose the kernel
manually anyway, and there will be an option in the warning prompt to
lower SV.

Since Security Version is meant to be a warning, not a hard block, we
can introduce a timeout to the warning prompt if necessary. The system
still boots, but with a longer boot time.

Gary Lin

> josh
> 
> > For more details: https://github.com/lcp/shim/wiki/Security-Version
> >
> > The original idea is to add a new PE/COFF section to store the data.
> > However, there are some restrictions.
> >
> > 1. For x86, the size limit of the EFI header is 0x200, and a section entry
> >in the section table takes 40 bytes. Currently, the EFI header already
> >occupies the first 0x1da bytes, so there is no room for a new section
> >entry.
> >
> > 2. The MemoryAttributes table sets the attributes of memory pages according
> >to the section flags. For ARM64, the minimal granularity is 4KB, but
> >Security Version only needs a few bytes, and it's pointless to allocate
> >4KB for it.
> >
> > Fortunately, there is a special section defined in PE/COFF: resource
> > section. The only known user of the resource section in UEFI is the HII
> > protocol which fetches data from "HII" directory. For Security Version, a
> > new directory called "LinuxSV" is created and it contains the file offset
> > to the struct of Security Version. The bootloader just follows the
> > resource table to fetch the "version" from the image file.
> >
> > v3:
> > - Move everything to the resource section to be compatible with both
> >   x86 and ARM64
> > v2:
> > - Decrease the size of secdata_offset to 2 bytes since the setup header
> >   is limited to around 32KB.
> > - Restructure the secdata section. The signer is now a null-terminated
> >   string. The type of distro_version changes to u32 in case the distro
> >   uses a long version.
> > - Modify the Kconfig names and add help.
> > - Remove the signer name hack in build.c.
> >
> > Cc: "H. Peter Anvin" 
> > Cc: Thomas Gleixner 
> > Cc: Ard Biesheuvel 
> > Cc: Ingo Molnar 
> > Cc: Matt Fleming 
> > Cc: Catalin Marinas 
> > Cc: Will Deacon 
> > Cc: Joey Lee 
> > Signed-off-by: Gary Lin 
> >
> > Gary Lin (2):
> >   x86/efi: Introduce Security Version to x86
> >   arm64/efi: Introduce Security Version to ARM64
> >
> >  arch/arm64/kernel/efi-header.S | 57 
> > ++
> >  arch/x86/boot/header.S | 55 
> > 
> >  drivers/firmware/efi/Kconfig   | 40 +
> >  3 files changed, 152 insertions(+)
> >
> > --
> > 2.15.0
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-efi" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub

[Josh Boyer]

On Tue, Dec 5, 2017 at 5:01 AM, Gary Lin  wrote:
> The series of patches introduce Security Version to EFI stub.
>
> Security Version is a monotonically increasing number and designed to
> prevent the user from loading an insecure kernel accidentally. The
> bootloader maintains a list of security versions corresponding to
> different distributions. After fixing a critical vulnerability, the
> distribution kernel maintainer bumps the "version", and the bootloader
> updates the list automatically. When the user tries to load a kernel
> with a lower security version, the bootloader shows a warning prompt
> to notify the user the potential risk.

If a distribution releases a kernel with a higher security version and
that it automatically updated on boot, what happens if that kernel
contains a different bug that causes it to fail to boot or break
critical functionality?  At that point, the user's machine would be in
a state where the higher security version is enforced but the only
kernel that provides that is broken.  Wouldn't that make a bad
situation even worse by now requiring manual acceptance of the older
SV kernel boot physically at the machine?

I feel like I'm missing a detail here or something.

josh

> For more details: https://github.com/lcp/shim/wiki/Security-Version
>
> The original idea is to add a new PE/COFF section to store the data.
> However, there are some restrictions.
>
> 1. For x86, the size limit of the EFI header is 0x200, and a section entry
>in the section table takes 40 bytes. Currently, the EFI header already
>occupies the first 0x1da bytes, so there is no room for a new section
>entry.
>
> 2. The MemoryAttributes table sets the attributes of memory pages according
>to the section flags. For ARM64, the minimal granularity is 4KB, but
>Security Version only needs a few bytes, and it's pointless to allocate
>4KB for it.
>
> Fortunately, there is a special section defined in PE/COFF: resource
> section. The only known user of the resource section in UEFI is the HII
> protocol which fetches data from "HII" directory. For Security Version, a
> new directory called "LinuxSV" is created and it contains the file offset
> to the struct of Security Version. The bootloader just follows the
> resource table to fetch the "version" from the image file.
>
> v3:
> - Move everything to the resource section to be compatible with both
>   x86 and ARM64
> v2:
> - Decrease the size of secdata_offset to 2 bytes since the setup header
>   is limited to around 32KB.
> - Restructure the secdata section. The signer is now a null-terminated
>   string. The type of distro_version changes to u32 in case the distro
>   uses a long version.
> - Modify the Kconfig names and add help.
> - Remove the signer name hack in build.c.
>
> Cc: "H. Peter Anvin" 
> Cc: Thomas Gleixner 
> Cc: Ard Biesheuvel 
> Cc: Ingo Molnar 
> Cc: Matt Fleming 
> Cc: Catalin Marinas 
> Cc: Will Deacon 
> Cc: Joey Lee 
> Signed-off-by: Gary Lin 
>
> Gary Lin (2):
>   x86/efi: Introduce Security Version to x86
>   arm64/efi: Introduce Security Version to ARM64
>
>  arch/arm64/kernel/efi-header.S | 57 
> ++
>  arch/x86/boot/header.S | 55 
>  drivers/firmware/efi/Kconfig   | 40 +
>  3 files changed, 152 insertions(+)
>
> --
> 2.15.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-efi" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub

[Josh Boyer]

On Tue, Dec 5, 2017 at 5:01 AM, Gary Lin  wrote:
> The series of patches introduce Security Version to EFI stub.
>
> Security Version is a monotonically increasing number and designed to
> prevent the user from loading an insecure kernel accidentally. The
> bootloader maintains a list of security versions corresponding to
> different distributions. After fixing a critical vulnerability, the
> distribution kernel maintainer bumps the "version", and the bootloader
> updates the list automatically. When the user tries to load a kernel
> with a lower security version, the bootloader shows a warning prompt
> to notify the user the potential risk.

If a distribution releases a kernel with a higher security version and
that it automatically updated on boot, what happens if that kernel
contains a different bug that causes it to fail to boot or break
critical functionality?  At that point, the user's machine would be in
a state where the higher security version is enforced but the only
kernel that provides that is broken.  Wouldn't that make a bad
situation even worse by now requiring manual acceptance of the older
SV kernel boot physically at the machine?

I feel like I'm missing a detail here or something.

josh

> For more details: https://github.com/lcp/shim/wiki/Security-Version
>
> The original idea is to add a new PE/COFF section to store the data.
> However, there are some restrictions.
>
> 1. For x86, the size limit of the EFI header is 0x200, and a section entry
>in the section table takes 40 bytes. Currently, the EFI header already
>occupies the first 0x1da bytes, so there is no room for a new section
>entry.
>
> 2. The MemoryAttributes table sets the attributes of memory pages according
>to the section flags. For ARM64, the minimal granularity is 4KB, but
>Security Version only needs a few bytes, and it's pointless to allocate
>4KB for it.
>
> Fortunately, there is a special section defined in PE/COFF: resource
> section. The only known user of the resource section in UEFI is the HII
> protocol which fetches data from "HII" directory. For Security Version, a
> new directory called "LinuxSV" is created and it contains the file offset
> to the struct of Security Version. The bootloader just follows the
> resource table to fetch the "version" from the image file.
>
> v3:
> - Move everything to the resource section to be compatible with both
>   x86 and ARM64
> v2:
> - Decrease the size of secdata_offset to 2 bytes since the setup header
>   is limited to around 32KB.
> - Restructure the secdata section. The signer is now a null-terminated
>   string. The type of distro_version changes to u32 in case the distro
>   uses a long version.
> - Modify the Kconfig names and add help.
> - Remove the signer name hack in build.c.
>
> Cc: "H. Peter Anvin" 
> Cc: Thomas Gleixner 
> Cc: Ard Biesheuvel 
> Cc: Ingo Molnar 
> Cc: Matt Fleming 
> Cc: Catalin Marinas 
> Cc: Will Deacon 
> Cc: Joey Lee 
> Signed-off-by: Gary Lin 
>
> Gary Lin (2):
>   x86/efi: Introduce Security Version to x86
>   arm64/efi: Introduce Security Version to ARM64
>
>  arch/arm64/kernel/efi-header.S | 57 
> ++
>  arch/x86/boot/header.S | 55 
>  drivers/firmware/efi/Kconfig   | 40 +
>  3 files changed, 152 insertions(+)
>
> --
> 2.15.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-efi" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub

[Gary Lin]

The series of patches introduce Security Version to EFI stub.

Security Version is a monotonically increasing number and designed to
prevent the user from loading an insecure kernel accidentally. The
bootloader maintains a list of security versions corresponding to
different distributions. After fixing a critical vulnerability, the
distribution kernel maintainer bumps the "version", and the bootloader
updates the list automatically. When the user tries to load a kernel
with a lower security version, the bootloader shows a warning prompt
to notify the user the potential risk.

For more details: https://github.com/lcp/shim/wiki/Security-Version

The original idea is to add a new PE/COFF section to store the data.
However, there are some restrictions.

1. For x86, the size limit of the EFI header is 0x200, and a section entry
   in the section table takes 40 bytes. Currently, the EFI header already
   occupies the first 0x1da bytes, so there is no room for a new section
   entry.

2. The MemoryAttributes table sets the attributes of memory pages according
   to the section flags. For ARM64, the minimal granularity is 4KB, but
   Security Version only needs a few bytes, and it's pointless to allocate
   4KB for it.

Fortunately, there is a special section defined in PE/COFF: resource
section. The only known user of the resource section in UEFI is the HII
protocol which fetches data from "HII" directory. For Security Version, a
new directory called "LinuxSV" is created and it contains the file offset
to the struct of Security Version. The bootloader just follows the
resource table to fetch the "version" from the image file.

v3:
- Move everything to the resource section to be compatible with both
  x86 and ARM64
v2:
- Decrease the size of secdata_offset to 2 bytes since the setup header
  is limited to around 32KB.
- Restructure the secdata section. The signer is now a null-terminated
  string. The type of distro_version changes to u32 in case the distro
  uses a long version.
- Modify the Kconfig names and add help.
- Remove the signer name hack in build.c.

Cc: "H. Peter Anvin" 
Cc: Thomas Gleixner 
Cc: Ard Biesheuvel 
Cc: Ingo Molnar 
Cc: Matt Fleming 
Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: Joey Lee 
Signed-off-by: Gary Lin 

Gary Lin (2):
  x86/efi: Introduce Security Version to x86
  arm64/efi: Introduce Security Version to ARM64

 arch/arm64/kernel/efi-header.S | 57 ++
 arch/x86/boot/header.S | 55 
 drivers/firmware/efi/Kconfig   | 40 +
 3 files changed, 152 insertions(+)

-- 
2.15.0

[RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub

[Gary Lin]

The series of patches introduce Security Version to EFI stub.

Security Version is a monotonically increasing number and designed to
prevent the user from loading an insecure kernel accidentally. The
bootloader maintains a list of security versions corresponding to
different distributions. After fixing a critical vulnerability, the
distribution kernel maintainer bumps the "version", and the bootloader
updates the list automatically. When the user tries to load a kernel
with a lower security version, the bootloader shows a warning prompt
to notify the user the potential risk.

For more details: https://github.com/lcp/shim/wiki/Security-Version

The original idea is to add a new PE/COFF section to store the data.
However, there are some restrictions.

1. For x86, the size limit of the EFI header is 0x200, and a section entry
   in the section table takes 40 bytes. Currently, the EFI header already
   occupies the first 0x1da bytes, so there is no room for a new section
   entry.

2. The MemoryAttributes table sets the attributes of memory pages according
   to the section flags. For ARM64, the minimal granularity is 4KB, but
   Security Version only needs a few bytes, and it's pointless to allocate
   4KB for it.

Fortunately, there is a special section defined in PE/COFF: resource
section. The only known user of the resource section in UEFI is the HII
protocol which fetches data from "HII" directory. For Security Version, a
new directory called "LinuxSV" is created and it contains the file offset
to the struct of Security Version. The bootloader just follows the
resource table to fetch the "version" from the image file.

v3:
- Move everything to the resource section to be compatible with both
  x86 and ARM64
v2:
- Decrease the size of secdata_offset to 2 bytes since the setup header
  is limited to around 32KB.
- Restructure the secdata section. The signer is now a null-terminated
  string. The type of distro_version changes to u32 in case the distro
  uses a long version.
- Modify the Kconfig names and add help.
- Remove the signer name hack in build.c.

Cc: "H. Peter Anvin" 
Cc: Thomas Gleixner 
Cc: Ard Biesheuvel 
Cc: Ingo Molnar 
Cc: Matt Fleming 
Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: Joey Lee 
Signed-off-by: Gary Lin 

Gary Lin (2):
  x86/efi: Introduce Security Version to x86
  arm64/efi: Introduce Security Version to ARM64

 arch/arm64/kernel/efi-header.S | 57 ++
 arch/x86/boot/header.S | 55 
 drivers/firmware/efi/Kconfig   | 40 +
 3 files changed, 152 insertions(+)

-- 
2.15.0