From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: ARC-Seal: i=1; a=rsa-sha256; t=1522796903; cv=none; d=google.com; s=arc-20160816; b=dwnPsMmO2eLh/jzLVU4oTNnxEMHvdec1WA3tDdAzEGnlz0ry5QBitYZjQSVQhH28zX ETxZcATSofuJClIN0KF1trN106nV35pjoQuCGNDXj1N7fnPeVsr4ygB7QI0PzJwJykxg L5uEM40ERpFGz3UYrCAT68Zsch7koS+aDZWCy8WQxYBzHBzRRm+r/4RWResAm+3mhs4O xx00cy0FQRO4RxocV0+N4wiLcMAVooC0a7lD32UW+yBJvJMbqVFvAZTGgV3uZ5e30DVC GF7fqZtQJgUtFEBPOmcVGZ2y+qbBgbex8xz3y8qWknb/tFgH7cH3SNAH6jT3lZSvLWWi XwFA== 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=4e/+XELhlmIKuQWujjGoUykDoS0AYV5waQqSY1mtJwo=; b=GAayiRn7oBDMNyYqRiClMeJik7arlZF8Ozf6bdM8N7Msx0VTUv6ojmJSGXlMcWz1tD GT2BnnwxolnTHjoCIfJ9anHC5ulGAvaSTc3YIWlDJpB3H6JJNmS9wHxpG+43S34lFUWt DgPN5b8/C9OFWQekxvyqrg56rbGRg+kThDw05GtHZ78bnOWY+Uj8gwCo2z0HusXGnPMw Ld5c6ui8I/tYI0DBIaWDrQiDwlRqUwT2fdKkm4BncP4IDkR6q+Mt1lR2XwnbZ/DrAv1F hn5q9LJ3XkuuP/4EUZbCkSFj+wykRmpw37tJRUR+eRT5U0Jg8R2kmxKhxbl7eIgeTcQM 9UtQ== 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: AIpwx48IjIzNfOFbv48+MJnREVpCp/edHEPirj30R3NvmKBcOgk6sRaGhJ3i2wODQXKERiYwhHWZepGFSL9mA8OrW1E= 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 18:08:22 -0500 Message-ID: Subject: Re: [GIT PULL] Kernel lockdown for secure boot To: Andy Lutomirski Cc: Matthew Garrett , Linus Torvalds , 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="0000000000007dda100568f9c829" X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1596407243846270411?= X-GMAIL-MSGID: =?utf-8?q?1596768286081310020?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: --0000000000007dda100568f9c829 Content-Type: text/plain; charset="UTF-8" On Tue, Apr 3, 2018 at 5:53 PM, Andy Lutomirski wrote: > On Tue, Apr 3, 2018 at 3:51 PM, Matthew Garrett wrote: > > On Tue, Apr 3, 2018 at 3:46 PM Linus Torvalds > > > > wrote: > > > >> For example, I love signed kernel modules. The fact that I love them > >> has absolutely zero to do with secure boot, though. There is > >> absolutely no linkage between the two issues: I use (self-)signed > >> kernel modules simply because I think it's a good thing in general. > > > >> The same thing is true of some lockdown patch. Maybe it's a good thing > >> in general. But whether it's a good thing is _entirely_ independent of > >> any secure boot issue. I can see using secure boot without it, but I > >> can very much also see using lockdown without secure boot. > > > >> The two things are simply entirely orthogonal. They have _zero_ > >> overlap. I'm not seeing why they'd be linked at all in any way. > > > > Lockdown is clearly useful without Secure Boot (and I intend to deploy it > > that way for various things), but I still don't understand why you feel > > that the common case of booting a kernel from a boot chain that's widely > > trusted derives no benefit from it being harder to subvert that kernel > into > > subverting that boot chain. For cases where you're self-signing and feel > > happy about that, you just set CONFIG_LOCK_DOWN_IN_EFI_SECURE_BOOT to n > and > > everyone's happy? > > I would like to see distros that want Secure Boot to annoy users by > enabling Lockdown be honest about the fact that it's an annoyance and > adds very little value by having to carry a patch that was rejected by > the upstream kernel. > > -Andy > They have been carrying those patches for *years* now. If we didn't think there was value in it, we wouldn't be carrying them. --0000000000007dda100568f9c829 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Apr 3, 2018 at 5:53 PM, Andy Lutomirski <<= a href=3D"mailto:luto@kernel.org" target=3D"_blank">luto@kernel.org>= wrote:
On Tue, Apr 3, 2018 at 3:51 PM, Matthew Garrett <mjg59@google.com> wrote:
> On Tue, Apr 3, 2018 at 3:46 PM Linus Torvalds
> <torvalds@linux-fo= undation.org>
> wrote:
>
>> For example, I love signed kernel modules. The fact that I love th= em
>> has absolutely zero to do with secure boot, though. There is
>> absolutely no linkage between the two issues: I use (self-)signed<= br> >> kernel modules simply because I think it's a good thing in gen= eral.
>
>> The same thing is true of some lockdown patch. Maybe it's a go= od thing
>> in general. But whether it's a good thing is _entirely_ indepe= ndent of
>> any secure boot issue. I can see using secure boot without it, but= I
>> can very much also see using lockdown without secure boot.
>
>> The two things are simply entirely orthogonal. They have _zero_ >> overlap. I'm not seeing why they'd be linked at all in any= way.
>
> Lockdown is clearly useful without Secure Boot (and I intend to deploy= it
> that way for various things), but I still don't understand why you= feel
> that the common case of booting a kernel from a boot chain that's = widely
> trusted derives no benefit from it being harder to subvert that kernel= into
> subverting that boot chain. For cases where you're self-signing an= d feel
> happy about that, you just set CONFIG_LOCK_DOWN_IN_EFI_SECURE_BOO= T to n and
> everyone's happy?

I would like to see distros that want Secure Boot to annoy user= s by
enabling Lockdown be honest about the fact that it's an annoyance and adds very little value by having to carry a patch that was rejected by
the upstream kernel.

-Andy

They = have been carrying those patches for *years* now. If we didn't think th= ere was value in it, we wouldn't be carrying them.

--0000000000007dda100568f9c829--