[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFywxADCF74ek0CadwcDaTySZ79aKHAp0K-p1LDT=G-GcA@mail.gmail.com>
Date: Wed, 15 Aug 2018 14:14:27 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: yannik@...britzki.me
Cc: Vivek Goyal <vgoyal@...hat.com>,
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>,
James Bottomley <James.Bottomley@...senpartnership.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 2:08 PM Yannik Sembritzki <yannik@...britzki.me> wrote:
>
> IMO, this is not okay. The layer of trust should extend from the bottom
> (user-provisioned platform key) up. Only trusting the kernel builtin key
> later on (wrt. kernel modules) contradicts this principal.
This module loading case is not about trusting the *key*.
This is about trusting the *build system*.
For example, I build my kernels with one single randomly generated key
(that gets deleted afterwards). The modules get built with that key
too.
No amount of added keys later will make a module valid to load.
Linus
Powered by blists - more mailing lists