linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: mingo@kernel.org (Ingo Molnar)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub
Date: Thu, 7 Dec 2017 07:09:27 +0100	[thread overview]
Message-ID: <20171207060927.i4b4h6ahas3iiyrc@gmail.com> (raw)
In-Reply-To: <20171207015903.jaos5siysggzz4nc@GaryWorkstation>


* Gary Lin <glin@suse.com> wrote:

> On Wed, Dec 06, 2017 at 07:37:34PM +0100, Ingo Molnar wrote:
> > 
> > * Gary Lin <glin@suse.com> 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 <glin@suse.com> 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

  reply	other threads:[~2017-12-07  6:09 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-05 10:01 [RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub Gary Lin
2017-12-05 10:01 ` [RFC v3 PATCH 1/2] x86/efi: Introduce Security Version to x86 Gary Lin
2017-12-05 10:01 ` [RFC v3 PATCH 2/2] arm64/efi: Introduce Security Version to ARM64 Gary Lin
2017-12-05 21:14 ` [RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub Josh Boyer
2017-12-06  3:24   ` Gary Lin
2017-12-06 18:37     ` Ingo Molnar
2017-12-07  1:59       ` Gary Lin
2017-12-07  6:09         ` Ingo Molnar [this message]
2017-12-07  7:52           ` Gary Lin
2017-12-07  8:18             ` Ingo Molnar
2017-12-07 10:27               ` Gary Lin
2017-12-07 10:35                 ` Ingo Molnar
2017-12-08  9:00                   ` Gary Lin
2017-12-07 14:26 ` Alan Cox
2017-12-08 10:03   ` Gary Lin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20171207060927.i4b4h6ahas3iiyrc@gmail.com \
    --to=mingo@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).