From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: ARC-Seal: i=1; a=rsa-sha256; t=1522805450; cv=none; d=google.com; s=arc-20160816; b=yQkWtTOvCiCp4CXJEp1ctq1Gxh9UpJ+jXzVSxzOHfrzOfhBHuacG1ZmpguttNE8+82 XYGmRpK+/69rDmEd3FGaJKOrr710JFtr69BVKodR6I4bNoIjGyimZpi50e3+jNBZlTXm efKs3+XAy9aWoyjtRjyTN+VNGuXCii88RSZThR+7CvDEgmECYaSzxBvtbEITgN/JQhCD PmgGtC5xyE/a0fosE2f2TQ5kmJ1TUfZPv6+mL6sR2IxFb2jBvhsrHIjEFwAPdZbcjMBx 46Egu1T8tbBKh+5M1xJ98i4B89sMBvjGwFC5ds9cE5KMhXDR95inm/B8O49alghi+e3u isPg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:arc-authentication-results; bh=M308pbioOzyXvLEDs5qW4O38uNlkmphbyaawTz/qTWs=; b=LHGgGacmggV2IktcGk6Eu+NcTrWU3TGQtUVzHVPEJ0OTcMQnsoIxyG7PAWUNYov3M5 i5se4OL/oDGDbYWVUQT4vt22bBaqERH0Sii5hbY4IQdxoz/ZKNsw+gX5dAWzFs4raIGu Rumme2DN3KJ6QeKog0e/jQLcaOhXKlMulm55j5tHE9JAMX05nYlUFSeVIvyHKicUTC3l p9i/9uWqksslnnaPy+fa65APlMZQW7HQDhNbOFt4j/7j6Uy45X5HwjQ/hLsTBzmSuwaJ gqGm0LNl6falYH26nn2cx659cKail4nRdwpN3HAz5MiDd3BkrPybMeDgbRyR9qEu1Yzj URJQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of jforbes@redhat.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=jforbes@redhat.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Authentication-Results: mx.google.com; spf=pass (google.com: domain of jforbes@redhat.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=jforbes@redhat.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com X-Google-Smtp-Source: AIpwx49u4kH0LxYopCD7OQHbe1fwKUit0stYNrbsu13kF49A4dvBgPhmr86FyZ4pSGicWBCSq7Begy8odOadkxOEB4M= MIME-Version: 1.0 In-Reply-To: References: <4136.1522452584@warthog.procyon.org.uk> <186aeb7e-1225-4bb8-3ff5-863a1cde86de@kernel.org> <30459.1522739219@warthog.procyon.org.uk> <9758.1522775763@warthog.procyon.org.uk> <13189.1522784944@warthog.procyon.org.uk> <9349.1522794769@warthog.procyon.org.uk> From: Justin Forbes Date: Tue, 3 Apr 2018 20:30:49 -0500 Message-ID: Subject: Re: [GIT PULL] Kernel lockdown for secure boot To: Linus Torvalds Cc: Matthew Garrett , Andrew Lutomirski , David Howells , Ard Biesheuvel , James Morris , Alan Cox , Greg Kroah-Hartman , Linux Kernel Mailing List , linux-man , joeyli , LSM List , Linux API , Kees Cook , linux-efi Content-Type: multipart/alternative; boundary="000000000000e27fd70568fbc536" X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1596407243846270411?= X-GMAIL-MSGID: =?utf-8?q?1596777247357017425?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: --000000000000e27fd70568fbc536 Content-Type: text/plain; charset="UTF-8" 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 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. --000000000000e27fd70568fbc536 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Apr 3, 2018 at 7:56 PM, Linus Torvalds <torvalds@l= inux-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 year= s.

.. so apparently it doesn't actually break things? Why not enabl= e it
by default then?

And if "turn off secure boot" really is the accepted - and actuia= lly
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 workaroun= d has always been "turn off secure boot" or sign/import your own = keys, depending on the problems encountered.=C2=A0
=C2=A0
=C2=A0 =C2=A0WHY THE HELL DIDN'T YOU START OFF BY EXPLAINING THAT IN TH= E 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 eve= ry time it comes to upstream, the same damn arguments emerge.=C2=A0 I do no= t disagree that there are uses for lockdown outside of secure boot, provide= d you have some other mechanism to verify your chain, I believe chrome OS d= oes. 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 tim= e for a pull request, people come out of the woodwork with an expectation t= hat it solves every problem or it doesn't need to exist. What is here i= s a good starting point. I would expect that if it were merged, others woul= d build upon that and use much of the code already in place to extend it. I= t is tied to secure boot because that is what has been using this for years= as it never seems to get upstream.=C2=A0 I am sure that once it does final= ly 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 pa= tch 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 her= e 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.
=C2=A0
--000000000000e27fd70568fbc536--