[Ksummit-discuss] [TECH TOPIC] Kernel lockdown and secure boot

[Ksummit-discuss] [TECH TOPIC] Kernel lockdown and secure boot

[David Howells]

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.

David

Re: [Ksummit-discuss] [TECH TOPIC] Kernel lockdown and secure boot

[Jiri Kosina]

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 ... ?

Thanks,

-- 
Jiri Kosina
SUSE Labs

Re: [Ksummit-discuss] [TECH TOPIC] Kernel lockdown and secure boot

[Justin Forbes]

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

Re: [Ksummit-discuss] [TECH TOPIC] Kernel lockdown and secure boot

[David Howells]

Justin Forbes <jmforbes@linuxtx.org> wrote:

> Lockdown is a config option on it's own, just also add a separate
> config option option to enable lockdown on UEFI secure boot.

The patchset has that already (CONFIG_LOCK_DOWN_IN_EFI_SECURE_BOOT).

One of the issues appears to be that we're making it boot-time conditional at
all.  If I understand him correctly, Linus seems to want us to make everything
locked down at compile time or not at all.

David

Re: [Ksummit-discuss] [TECH TOPIC] Kernel lockdown and secure boot

[Justin Forbes]

On Wed, Sep 5, 2018 at 3:14 PM, David Howells <dhowells@redhat.com> wrote:
> Justin Forbes <jmforbes@linuxtx.org> wrote:
>
>> Lockdown is a config option on it's own, just also add a separate
>> config option option to enable lockdown on UEFI secure boot.
>
> The patchset has that already (CONFIG_LOCK_DOWN_IN_EFI_SECURE_BOOT).
>
> One of the issues appears to be that we're making it boot-time conditional at
> all.  If I understand him correctly, Linus seems to want us to make everything
> locked down at compile time or not at all.
>

The last push attempt dropped that patch and did have the compile time
(CONFIG_LOCK_DOWN_MANDATORY) as well as an option for command line
enabling with lockdown=1 (CONFIG_LOCK_DOWN_KERNEL).  It just didn't
have an option for triggering off of UEFI Secure Boot.   As a distro,
running   CONFIG_LOCK_DOWN_MANDATORY isn't much of an option. We ran
the 4.17 development series in rawhide with CONFIG_LOCK_DOWN_KERNEL,
and no one noticed that their secure boot was off.  This is why it is
somewhat frightening to change the behavior, users assume it is all
working because things boot, and never notice they are missing some
protection that they assumed was there.  Before we rebased stable
distros I reworked the CONFIG_LOCK_DOWN_IN_EFI_SECURE_BOOT to work
with the current patch set and that is what we are carrying now.
While I would love to see everything pushed as a whole, I would still
be much happier than I am now if everything else pushed and we only
had to carry the patch to trigger off of UEFI status.  It is a minor
detail that shouldn't be blocking the entire patch set at this point.
If Linus agrees that it can be pushed with CONFIG_LOCK_DOWN_MANDATORY
as the only option, that is fine. Still much less out of tree for us
to worry about.

Re: [Ksummit-discuss] [TECH TOPIC] Kernel lockdown and secure boot

[Andy Lutomirski]

On Wed, Sep 5, 2018 at 1:34 PM, Justin Forbes <jmforbes@linuxtx.org> wrote:
> On Wed, Sep 5, 2018 at 3:14 PM, David Howells <dhowells@redhat.com> wrote:
>> Justin Forbes <jmforbes@linuxtx.org> wrote:
>>
>>> Lockdown is a config option on it's own, just also add a separate
>>> config option option to enable lockdown on UEFI secure boot.
>>
>> The patchset has that already (CONFIG_LOCK_DOWN_IN_EFI_SECURE_BOOT).
>>
>> One of the issues appears to be that we're making it boot-time conditional at
>> all.  If I understand him correctly, Linus seems to want us to make everything
>> locked down at compile time or not at all.
>>
>
> The last push attempt dropped that patch and did have the compile time
> (CONFIG_LOCK_DOWN_MANDATORY) as well as an option for command line
> enabling with lockdown=1 (CONFIG_LOCK_DOWN_KERNEL).  It just didn't
> have an option for triggering off of UEFI Secure Boot.   As a distro,
> running   CONFIG_LOCK_DOWN_MANDATORY isn't much of an option. We ran
> the 4.17 development series in rawhide with CONFIG_LOCK_DOWN_KERNEL,
> and no one noticed that their secure boot was off.  This is why it is
> somewhat frightening to change the behavior, users assume it is all
> working because things boot, and never notice they are missing some
> protection that they assumed was there.  Before we rebased stable
> distros I reworked the CONFIG_LOCK_DOWN_IN_EFI_SECURE_BOOT to work
> with the current patch set and that is what we are carrying now.
> While I would love to see everything pushed as a whole, I would still
> be much happier than I am now if everything else pushed and we only
> had to carry the patch to trigger off of UEFI status.  It is a minor
> detail that shouldn't be blocking the entire patch set at this point.
> If Linus agrees that it can be pushed with CONFIG_LOCK_DOWN_MANDATORY
> as the only option, that is fine. Still much less out of tree for us
> to worry about.

I'm not really convinced this needs a whole tech topic.  I send an
email awhile back, but didn't hear back, so here goes roughly again:

As far as I can tell, there are two issues blocking lockdown, both of
which should be relatively easily resolvable:

1. When exactly is lockdown enabled?

2. What exactly does lockdown do?

#1 is clearly resolvable.  Worst case, a bare minimum version can get
merged where, for example, lockdown is either mandatory or is enabled
by boot option.  Distros can carry a patch for alternative policies
for a little while until the dust settles.

#2 is a bigger deal.  At least one version that shipped in a Fedora
kernel actually broke systemd, and that's not cool.  And I really
think we need to make lockdown non-binary to get this right.  I've
proposed LOCKDOWN_PROTECT_INTEGRITY (i.e. try to prevent root from
modifying the running kernel) and LOCKDOWN_PROTECT_SECRECY (try to
prevent root from reading kernel memory), and no one seems to have
actually objected.

So I would propose the following.  Someone (me? David?) prepares a
very stripped down lockdown patchset.  It adds the basic config
options for CONFIG_LOCK_DOWN_KERNEL and whatever compile-time
mandatory variants we want, and it adds the helpers so various
subsystems can ask whether lockdown is on.  And it adds one single
lockdown user in the kernel.  And we merge that.  Then we add
additional lockdown users one at a time.

This will resolve what I see as the major issue that has blocked
lockdown: the patchset is too big and spans too many subsystems.
Every time it's submitted it gets bogged down in important but
distracting discussions like "what, exactly, should the following bpf
feature do in lockdown mode?".  These matter, but there is no
legitimate reason for them to block the overall feature -- it's
entirely fine if the initial version of lockdown doesn't protect bpf
at all.

--Andy

[There's only a ~30% change I can make LPC this year...]

Re: [Ksummit-discuss] [TECH TOPIC] Kernel lockdown and secure boot

[Justin Forbes]

On Wed, Sep 5, 2018 at 3:53 PM, Andy Lutomirski <luto@kernel.org> wrote:
> On Wed, Sep 5, 2018 at 1:34 PM, Justin Forbes <jmforbes@linuxtx.org> wrote:
>> On Wed, Sep 5, 2018 at 3:14 PM, David Howells <dhowells@redhat.com> wrote:
>>> Justin Forbes <jmforbes@linuxtx.org> wrote:
>>>
>>>> Lockdown is a config option on it's own, just also add a separate
>>>> config option option to enable lockdown on UEFI secure boot.
>>>
>>> The patchset has that already (CONFIG_LOCK_DOWN_IN_EFI_SECURE_BOOT).
>>>
>>> One of the issues appears to be that we're making it boot-time conditional at
>>> all.  If I understand him correctly, Linus seems to want us to make everything
>>> locked down at compile time or not at all.
>>>
>>
>> The last push attempt dropped that patch and did have the compile time
>> (CONFIG_LOCK_DOWN_MANDATORY) as well as an option for command line
>> enabling with lockdown=1 (CONFIG_LOCK_DOWN_KERNEL).  It just didn't
>> have an option for triggering off of UEFI Secure Boot.   As a distro,
>> running   CONFIG_LOCK_DOWN_MANDATORY isn't much of an option. We ran
>> the 4.17 development series in rawhide with CONFIG_LOCK_DOWN_KERNEL,
>> and no one noticed that their secure boot was off.  This is why it is
>> somewhat frightening to change the behavior, users assume it is all
>> working because things boot, and never notice they are missing some
>> protection that they assumed was there.  Before we rebased stable
>> distros I reworked the CONFIG_LOCK_DOWN_IN_EFI_SECURE_BOOT to work
>> with the current patch set and that is what we are carrying now.
>> While I would love to see everything pushed as a whole, I would still
>> be much happier than I am now if everything else pushed and we only
>> had to carry the patch to trigger off of UEFI status.  It is a minor
>> detail that shouldn't be blocking the entire patch set at this point.
>> If Linus agrees that it can be pushed with CONFIG_LOCK_DOWN_MANDATORY
>> as the only option, that is fine. Still much less out of tree for us
>> to worry about.
>
> I'm not really convinced this needs a whole tech topic.  I send an
> email awhile back, but didn't hear back, so here goes roughly again:
>
> As far as I can tell, there are two issues blocking lockdown, both of
> which should be relatively easily resolvable:
>
> 1. When exactly is lockdown enabled?
>
> 2. What exactly does lockdown do?
>
> #1 is clearly resolvable.  Worst case, a bare minimum version can get
> merged where, for example, lockdown is either mandatory or is enabled
> by boot option.  Distros can carry a patch for alternative policies
> for a little while until the dust settles.
>
> #2 is a bigger deal.  At least one version that shipped in a Fedora
> kernel actually broke systemd, and that's not cool.  And I really
> think we need to make lockdown non-binary to get this right.  I've
> proposed LOCKDOWN_PROTECT_INTEGRITY (i.e. try to prevent root from
> modifying the running kernel) and LOCKDOWN_PROTECT_SECRECY (try to
> prevent root from reading kernel memory), and no one seems to have
> actually objected.
>
The Fedora issue was the bpf hammer. I am looking to find a better
solution for that one, but dropped the patch in the meantime. It was
removed shortly after it was found.  This is one of the many reasons I
don't like all or nothing at compile time, but again, we can carry the
patch to toggle separately until a better solution is worked out.

> So I would propose the following.  Someone (me? David?) prepares a
> very stripped down lockdown patchset.  It adds the basic config
> options for CONFIG_LOCK_DOWN_KERNEL and whatever compile-time
> mandatory variants we want, and it adds the helpers so various
> subsystems can ask whether lockdown is on.  And it adds one single
> lockdown user in the kernel.  And we merge that.  Then we add
> additional lockdown users one at a time.
>
I would be fine with this, I just want some sort of path forward.

> This will resolve what I see as the major issue that has blocked
> lockdown: the patchset is too big and spans too many subsystems.
> Every time it's submitted it gets bogged down in important but
> distracting discussions like "what, exactly, should the following bpf
> feature do in lockdown mode?".  These matter, but there is no
> legitimate reason for them to block the overall feature -- it's
> entirely fine if the initial version of lockdown doesn't protect bpf
> at all.
>
> --Andy
>
> [There's only a ~30% change I can make LPC this year...]

If you can make it, I will certainly be there and would be happy to
discuss moving this forward.

Re: [Ksummit-discuss] [TECH TOPIC] Kernel lockdown and secure boot

[joeyli]

Hi,

On Wed, Sep 05, 2018 at 04:01:12PM -0500, Justin Forbes wrote:
> On Wed, Sep 5, 2018 at 3:53 PM, Andy Lutomirski <luto@kernel.org> wrote:
> > On Wed, Sep 5, 2018 at 1:34 PM, Justin Forbes <jmforbes@linuxtx.org> wrote:
> >> On Wed, Sep 5, 2018 at 3:14 PM, David Howells <dhowells@redhat.com> wrote:
> >>> Justin Forbes <jmforbes@linuxtx.org> wrote:
> >>>
> >>>> Lockdown is a config option on it's own, just also add a separate
> >>>> config option option to enable lockdown on UEFI secure boot.
> >>>
> >>> The patchset has that already (CONFIG_LOCK_DOWN_IN_EFI_SECURE_BOOT).
> >>>
> >>> One of the issues appears to be that we're making it boot-time conditional at
> >>> all.  If I understand him correctly, Linus seems to want us to make everything
> >>> locked down at compile time or not at all.
> >>>
> >>
> >> The last push attempt dropped that patch and did have the compile time
> >> (CONFIG_LOCK_DOWN_MANDATORY) as well as an option for command line
> >> enabling with lockdown=1 (CONFIG_LOCK_DOWN_KERNEL).  It just didn't
> >> have an option for triggering off of UEFI Secure Boot.   As a distro,
> >> running   CONFIG_LOCK_DOWN_MANDATORY isn't much of an option. We ran
> >> the 4.17 development series in rawhide with CONFIG_LOCK_DOWN_KERNEL,
> >> and no one noticed that their secure boot was off.  This is why it is
> >> somewhat frightening to change the behavior, users assume it is all
> >> working because things boot, and never notice they are missing some
> >> protection that they assumed was there.  Before we rebased stable
> >> distros I reworked the CONFIG_LOCK_DOWN_IN_EFI_SECURE_BOOT to work
> >> with the current patch set and that is what we are carrying now.
> >> While I would love to see everything pushed as a whole, I would still
> >> be much happier than I am now if everything else pushed and we only
> >> had to carry the patch to trigger off of UEFI status.  It is a minor
> >> detail that shouldn't be blocking the entire patch set at this point.
> >> If Linus agrees that it can be pushed with CONFIG_LOCK_DOWN_MANDATORY
> >> as the only option, that is fine. Still much less out of tree for us
> >> to worry about.
> >
> > I'm not really convinced this needs a whole tech topic.  I send an
> > email awhile back, but didn't hear back, so here goes roughly again:
> >
> > As far as I can tell, there are two issues blocking lockdown, both of
> > which should be relatively easily resolvable:
> >
> > 1. When exactly is lockdown enabled?
> >
> > 2. What exactly does lockdown do?
> >
> > #1 is clearly resolvable.  Worst case, a bare minimum version can get
> > merged where, for example, lockdown is either mandatory or is enabled
> > by boot option.  Distros can carry a patch for alternative policies
> > for a little while until the dust settles.
> >
> > #2 is a bigger deal.  At least one version that shipped in a Fedora
> > kernel actually broke systemd, and that's not cool.  And I really
> > think we need to make lockdown non-binary to get this right.  I've
> > proposed LOCKDOWN_PROTECT_INTEGRITY (i.e. try to prevent root from
> > modifying the running kernel) and LOCKDOWN_PROTECT_SECRECY (try to
> > prevent root from reading kernel memory), and no one seems to have
> > actually objected.
> >
> The Fedora issue was the bpf hammer. I am looking to find a better
> solution for that one, but dropped the patch in the meantime. It was
> removed shortly after it was found.  This is one of the many reasons I
> don't like all or nothing at compile time, but again, we can carry the
> patch to toggle separately until a better solution is worked out.
>

I have thought a approach to give user a fine-grained switch to unlock
individual locked-down function by a authenticatabled function list
blob. The blob must be verified by the keys in kernel trusted keyring
(e.g. kernel compiled-in key or MOK). Maybe add timestamp to prevent
replay attack. Then kernel unlocked functions base on the list in the
authenticatabled blob from user who hosts private key.
 
> > So I would propose the following.  Someone (me? David?) prepares a
> > very stripped down lockdown patchset.  It adds the basic config
> > options for CONFIG_LOCK_DOWN_KERNEL and whatever compile-time
> > mandatory variants we want, and it adds the helpers so various
> > subsystems can ask whether lockdown is on.  And it adds one single
> > lockdown user in the kernel.  And we merge that.  Then we add
> > additional lockdown users one at a time.
> >
> I would be fine with this, I just want some sort of path forward.
>

I also agree this approach. At least we can have a simple start in
kernel mainline.
 
> > This will resolve what I see as the major issue that has blocked
> > lockdown: the patchset is too big and spans too many subsystems.
> > Every time it's submitted it gets bogged down in important but
> > distracting discussions like "what, exactly, should the following bpf
> > feature do in lockdown mode?".  These matter, but there is no
> > legitimate reason for them to block the overall feature -- it's
> > entirely fine if the initial version of lockdown doesn't protect bpf
> > at all.
> >
> > --Andy
> >
> > [There's only a ~30% change I can make LPC this year...]
> 
> If you can make it, I will certainly be there and would be happy to
> discuss moving this forward.

Me too.

Thanks a lot!
Joey Lee

Re: [Ksummit-discuss] [TECH TOPIC] Kernel lockdown and secure boot

[Jani Nikula]

On Wed, 05 Sep 2018, Andy Lutomirski <luto@kernel.org> wrote:
> 2. What exactly does lockdown do?
>
> #2 is a bigger deal.  At least one version that shipped in a Fedora
> kernel actually broke systemd, and that's not cool.  And I really
> think we need to make lockdown non-binary to get this right.  I've
> proposed LOCKDOWN_PROTECT_INTEGRITY (i.e. try to prevent root from
> modifying the running kernel) and LOCKDOWN_PROTECT_SECRECY (try to
> prevent root from reading kernel memory), and no one seems to have
> actually objected.

Clueless bystander comment: I spent a while debugging a bug reporter's
-EPERM issue on direct PCI bar access. Took me a while to realize this
was caused by kernel lockdown on the user's distro. I expect more issues
like this to pop up as the use of lockdown proliferates, and I don't
think it's necessarily obvious when lockdown changes behaviour.

I guess I'm asking, have you considered an audit log for lockdown
blocked access, and if you've rejected the idea, why?

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [Ksummit-discuss] [TECH TOPIC] Kernel lockdown and secure boot

[David Howells]

Jani Nikula <jani.nikula@intel.com> wrote:

> I guess I'm asking, have you considered an audit log for lockdown
> blocked access, and if you've rejected the idea, why?

It logs a message to dmesg telling you what caused the rejection.

David

Re: [Ksummit-discuss] [TECH TOPIC] Kernel lockdown and secure boot

[Jani Nikula]

On Thu, 06 Sep 2018, David Howells <dhowells@redhat.com> wrote:
> Jani Nikula <jani.nikula@intel.com> wrote:
>
>> I guess I'm asking, have you considered an audit log for lockdown
>> blocked access, and if you've rejected the idea, why?
>
> It logs a message to dmesg telling you what caused the rejection.

Ah, good. Looks like this was added at some point, and the user was
running kernel lockdown without this.

Thanks,
Jani.


-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [Ksummit-discuss] [TECH TOPIC] Kernel lockdown and secure boot

[Mauro Carvalho Chehab]

Em Wed, 5 Sep 2018 15:34:04 -0500
Justin Forbes <jmforbes@linuxtx.org> escreveu:

> On Wed, Sep 5, 2018 at 3:14 PM, David Howells <dhowells@redhat.com> wrote:
> > Justin Forbes <jmforbes@linuxtx.org> wrote:
> >  
> >> Lockdown is a config option on it's own, just also add a separate
> >> config option option to enable lockdown on UEFI secure boot.  
> >
> > The patchset has that already (CONFIG_LOCK_DOWN_IN_EFI_SECURE_BOOT).
> >
> > One of the issues appears to be that we're making it boot-time conditional at
> > all.  If I understand him correctly, Linus seems to want us to make everything
> > locked down at compile time or not at all.
> >  
> 
> The last push attempt dropped that patch and did have the compile time
> (CONFIG_LOCK_DOWN_MANDATORY) as well as an option for command line
> enabling with lockdown=1 (CONFIG_LOCK_DOWN_KERNEL).  It just didn't
> have an option for triggering off of UEFI Secure Boot.   As a distro,
> running   CONFIG_LOCK_DOWN_MANDATORY isn't much of an option. We ran
> the 4.17 development series in rawhide with CONFIG_LOCK_DOWN_KERNEL,
> and no one noticed that their secure boot was off.  

Heh, I actually had to turn secure boot off due to that :-)

(long story short, it was on an Intel 8 gen CPU with Radeon GPU on it,
with required 4.17 + DRM for 4.18 in order to detect my 3 monitors,
so I had to build my own kernel, not signed by Red Hat).

Thanks,
Mauro