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]
Date:   Wed, 15 Aug 2018 17:57:18 -0400
From:   Vivek Goyal <vgoyal@...hat.com>
To:     Yannik Sembritzki <yannik@...britzki.me>
Cc:     James Bottomley <James.Bottomley@...senPartnership.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        David Howells <dhowells@...hat.com>,
        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

On Wed, Aug 15, 2018 at 11:31:27PM +0200, Yannik Sembritzki wrote:
> On 15.08.2018 23:13, James Bottomley wrote:
> > Consider a UEFI system for which a user has taken ownership, but which
> > has some signed ROMs which are UEFI secure boot verified.  Simply to
> > get their system to boot the user will be forced to add the ODM key to
> > the UEFI db ... and I'm sure in that situation the user wouldn't want
> > to trust the ODM key further than booting.
> I definitely agree with this point.
> 
> Is there any solution, except from building your own kernel, to the
> scenario I described?
> I think there should be.
> (I've personally run into this with VirtualBox, which I IIRC couldn't
> load, even though I provisioned my own PK, and signed both kernel and
> VirtualBox module with my own key. I could've compiled my own kernel
> with my //own key, but that is pretty impractical for most users.)

Aha.., so that's your real problem. You are trying to load VirtualBox
module and that will not load even if you take ownership of platform
by adding your key and sign module with that key.

So this patch still will not fix the problem you are facing. It is still
good to fix the case of kexec/kdump broken on Fedora on secureboot
machines.

Thanks
Vivek

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ