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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Fri, 8 Dec 2017 18:03:02 +0800
From:   Gary Lin <glin@...e.com>
To:     Alan Cox <gnomes@...rguk.ukuu.org.uk>
Cc:     x86@...nel.org, linux-kernel@...r.kernel.org,
        linux-efi@...r.kernel.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 02:26:57PM +0000, Alan Cox wrote:
> On Tue,  5 Dec 2017 18:01:46 +0800
> 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. 
> 
> 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