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] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 16 Aug 2018 16:56:59 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'James Bottomley' <James.Bottomley@...senPartnership.com>,
        David Howells <dhowells@...hat.com>
CC:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Vivek Goyal <vgoyal@...hat.com>,
        "yannik@...britzki.me" <yannik@...britzki.me>,
        "Thomas Gleixner" <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Peter Anvin <hpa@...or.com>,
        the arch/x86 maintainers <x86@...nel.org>,
        "Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
        Dave Young <dyoung@...hat.com>, Baoquan He <bhe@...hat.com>,
        Justin Forbes <jforbes@...hat.com>,
        Peter Jones <pjones@...hat.com>,
        Matthew Garrett <mjg59@...gle.com>
Subject: RE: [PATCH] Fix kexec forbidding kernels signed with custom platform
 keys to boot

From: James Bottomley
> Sent: 16 August 2018 16:57
> On Thu, 2018-08-16 at 16:49 +0100, David Howells wrote:
> > James Bottomley <James.Bottomley@...senPartnership.com> wrote:
> >
> > > > The problem with that is that it means you can't load third party
> > > > modules - such as the NVidia driver.  That's fine if you
> > > > absolutely reject the right of people to produce third party
> > > > drivers for the Linux kernel and absolutely require that they
> > > > open and upstream their code if they want in.
> > >
> > > So if you build your own kernel and want to load the nVidia module,
> > > you have the key to sign it.
> >
> > I think you have to assume that doing this is beyond most people.
> 
> As a step by step process, I agree.  However, I think we can automate
> it to the point where you install a package and it says "insert your
> yubikey" every time you upgrade the kernel

What about 3rd parties that want to release drivers that can be loaded
into 'distribution' kernels?
We can do that for windows (provided we've paid the 'driver signing tax')
because windows has a stable kernel DDI/DKI.
For Linux we have to release most of the driver as a binary 'blob' and
compile wrapper code on the target system with the correct kernel headers.
There is no way we could generate signed copies for every 'distribution'
kernel - even if there was a way to get them signed.
Even if we agreed to make our source code available it wouldn't be
accepted for inclusion in the kernel source tree.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ