[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFwJd_AqrnrKfiCX++pWqrTuoduKUKhEwxvx=wVhMaQH3g@mail.gmail.com>
Date: Tue, 3 Apr 2018 16:27:28 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: David Howells <dhowells@...hat.com>
Cc: Andy Lutomirski <luto@...nel.org>,
Matthew Garrett <mjg59@...gle.com>,
Ard Biesheuvel <ard.biesheuvel@...aro.org>,
James Morris <jmorris@...ei.org>,
Alan Cox <gnomes@...rguk.ukuu.org.uk>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Justin Forbes <jforbes@...hat.com>,
linux-man <linux-man@...r.kernel.org>, joeyli <jlee@...e.com>,
LSM List <linux-security-module@...r.kernel.org>,
Linux API <linux-api@...r.kernel.org>,
Kees Cook <keescook@...omium.org>,
linux-efi <linux-efi@...r.kernel.org>
Subject: Re: [GIT PULL] Kernel lockdown for secure boot
On Tue, Apr 3, 2018 at 4:12 PM, David Howells <dhowells@...hat.com> wrote:
>
> What use is secure boot if processes run as root can subvert your kernel?
Stop this idiocy.
The above has now been answered multiple times, several different ways.
The "point" of secure boot may be that you had no choice, or there was
no point at all, it just came that way.
Or the "point" of secure boot may be that you don't trust anybody else
than yourself, but once you've booted you do trust what you booted.
But the *real* point is that this has nothing what-so-ever to do with
secure boot. You may want (or not want) lockdown independently of it.
Don't tie magic boot issues with kernel runtime behavior.
Linus
Powered by blists - more mailing lists