Re: [GIT PULL] Kernel lockdown for secure boot

[Justin Forbes <jforbes@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2590 bytes --]

On Tue, Apr 3, 2018 at 7:56 PM, Linus Torvalds <
torvalds@linux-foundation.org> wrote:

> On Tue, Apr 3, 2018 at 5:46 PM, Matthew Garrett <mjg59@google.com> wrote:
> >
> > The generic distros have been shipping this policy for the past 5 years.
>
> .. so apparently it doesn't actually break things? Why not enable it
> by default then?
>
> And if "turn off secure boot" really is the accepted - and actuially
> used - workaround for the breakage, then
>
> While there is very little breakage in the *years* we have been shipping
this in distro kernels, the accepted and used workaround has always been
"turn off secure boot" or sign/import your own keys, depending on the
problems encountered.


>    WHY THE HELL DIDN'T YOU START OFF BY EXPLAINING THAT IN THE FIRST
> PLACE WHEN PEOPLE ASKED WHY THE TIE-IN EXISTED?
>
> Sorry for shouting, but really. We have a thread of just *how* many
> email messages that asked for the explanation for this? All we got was
> incomprehensible and illogical crap explanations.

If there actually was a good explanation for the tie-in, it should
> have been front-and-center and explained as such.
>
> Honestly, yes, the major distros have been shipping this patch set for
years now, and every time it comes to upstream, the same damn arguments
emerge.  I do not disagree that there are uses for lockdown outside of
secure boot, provided you have some other mechanism to verify your chain, I
believe chrome OS does. But the tie to secure boot is because that is the
use case that users have been using for years, it was discussed at kernel
summit quite a while ago, plans went forward there seemed to be agreement,
and when it comes time for a pull request, people come out of the woodwork
with an expectation that it solves every problem or it doesn't need to
exist. What is here is a good starting point. I would expect that if it
were merged, others would build upon that and use much of the code already
in place to extend it. It is tied to secure boot because that is what has
been using this for years as it never seems to get upstream.  I am sure
that once it does finally land, it can and will be extended to other
things, but I don't think I would want to spend a lot of time trying to
leverage another external patch set that has been delayed upstream so many
times until it actually did land.
As for the ties to MS that come up every time, and have here as well, there
is no requirement on the MS signature. You can import your own keys if you
don't want them involved, I keep a "test key" imported for actually running
what I build locally.

[-- Attachment #2: Type: text/html, Size: 3415 bytes --]