ksummit.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Justin Forbes <jmforbes@linuxtx.org>
To: Jiri Kosina <jikos@kernel.org>
Cc: James.Bottomley@hansenpartnership.com,
	Peter Jones <pjones@redhat.com>,
	joeyli.kernel@gmail.com,
	ksummit-discuss@lists.linuxfoundation.org
Subject: Re: [Ksummit-discuss] [TECH TOPIC] Kernel lockdown and secure boot
Date: Wed, 5 Sep 2018 14:51:46 -0500	[thread overview]
Message-ID: <CAFxkdAp6FxwT5XO9C_4_naSTEzs4iFosj+ijbK0rfW8FsyuMsA@mail.gmail.com> (raw)
In-Reply-To: <nycvar.YFH.7.76.1809052132190.15880@cbobk.fhfr.pm>

On Wed, Sep 5, 2018 at 2:33 PM, Jiri Kosina <jikos@kernel.org> wrote:
> On Wed, 5 Sep 2018, David Howells wrote:
>
>> I would like to suggest having a kernel summit session on how to
>> progress the secure boot and kernel lockdown patches.  AIUI, various
>> distributions are actually including them in their kernels.
>
> FWIW, it's one of the rare exceptions where we are carrying non-upstream
> patchset in our tree, yes.
>
> I have to admit I already forgot what exactly was actually blocking the
> upstream merge ... ?
>
It seems to vary by merge attempt, but last time, there was some very
good discussion about lockdown being separated from secure boot. I
personally don't see a problem with that, it is a decent idea.
Lockdown is a config option on it's own, just also add a separate
config option option to enable lockdown on UEFI secure boot.  That way
people who want lockdown independent of secure boot can have it, and
distros who want to keep the current behavior can also do that.
There are also some more recent issues with BPF, the current lockdown
solution of "disable it" is a large hammer, and causes problems with
IPAddressAllow/IPAddressDeny.

Justin

  reply	other threads:[~2018-09-05 19:51 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-05 16:53 David Howells
2018-09-05 19:33 ` Jiri Kosina
2018-09-05 19:51   ` Justin Forbes [this message]
2018-09-05 20:14   ` David Howells
2018-09-05 20:34     ` Justin Forbes
2018-09-05 20:53       ` Andy Lutomirski
2018-09-05 21:01         ` Justin Forbes
2018-09-06  6:53           ` joeyli
2018-09-06 10:00         ` Jani Nikula
2018-09-06 10:05         ` David Howells
2018-09-06 10:21           ` Jani Nikula
2018-09-07 19:53       ` Mauro Carvalho Chehab

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAFxkdAp6FxwT5XO9C_4_naSTEzs4iFosj+ijbK0rfW8FsyuMsA@mail.gmail.com \
    --to=jmforbes@linuxtx.org \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=jikos@kernel.org \
    --cc=joeyli.kernel@gmail.com \
    --cc=ksummit-discuss@lists.linuxfoundation.org \
    --cc=pjones@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox