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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20171207075203.gcxprq7ctv637fm7@GaryWorkstation>
Date:   Thu, 7 Dec 2017 15:52:04 +0800
From:   Gary Lin <glin@...e.com>
To:     Ingo Molnar <mingo@...nel.org>
Cc:     Josh Boyer <jwboyer@...oraproject.org>, x86 <x86@...nel.org>,
        "Linux-Kernel@...r. Kernel. Org" <linux-kernel@...r.kernel.org>,
        "linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "H. Peter Anvin" <hpa@...or.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ard Biesheuvel <ard.biesheuvel@...aro.org>,
        Ingo Molnar <mingo@...hat.com>,
        Matt Fleming <matt@...eblueprint.co.uk>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will.deacon@....com>, Joey Lee <jlee@...e.com>
Subject: Re: [RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub

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