* [Ksummit-discuss] [TECH TOPIC] Kernel lockdown and secure boot @ 2018-09-05 16:53 David Howells 2018-09-05 19:33 ` Jiri Kosina 0 siblings, 1 reply; 12+ messages in thread From: David Howells @ 2018-09-05 16:53 UTC (permalink / raw) To: ksummit-discuss; +Cc: James.Bottomley, pjones, jmforbes, joeyli.kernel 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Ksummit-discuss] [TECH TOPIC] Kernel lockdown and secure boot 2018-09-05 16:53 [Ksummit-discuss] [TECH TOPIC] Kernel lockdown and secure boot David Howells @ 2018-09-05 19:33 ` Jiri Kosina 2018-09-05 19:51 ` Justin Forbes 2018-09-05 20:14 ` David Howells 0 siblings, 2 replies; 12+ messages in thread From: Jiri Kosina @ 2018-09-05 19:33 UTC (permalink / raw) To: David Howells Cc: James.Bottomley, pjones, jmforbes, joeyli.kernel, ksummit-discuss 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Ksummit-discuss] [TECH TOPIC] Kernel lockdown and secure boot 2018-09-05 19:33 ` Jiri Kosina @ 2018-09-05 19:51 ` Justin Forbes 2018-09-05 20:14 ` David Howells 1 sibling, 0 replies; 12+ messages in thread From: Justin Forbes @ 2018-09-05 19:51 UTC (permalink / raw) To: Jiri Kosina; +Cc: James.Bottomley, Peter Jones, joeyli.kernel, ksummit-discuss 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Ksummit-discuss] [TECH TOPIC] Kernel lockdown and secure boot 2018-09-05 19:33 ` Jiri Kosina 2018-09-05 19:51 ` Justin Forbes @ 2018-09-05 20:14 ` David Howells 2018-09-05 20:34 ` Justin Forbes 1 sibling, 1 reply; 12+ messages in thread From: David Howells @ 2018-09-05 20:14 UTC (permalink / raw) To: Justin Forbes Cc: James.Bottomley, joeyli.kernel, ksummit-discuss, Peter Jones 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Ksummit-discuss] [TECH TOPIC] Kernel lockdown and secure boot 2018-09-05 20:14 ` David Howells @ 2018-09-05 20:34 ` Justin Forbes 2018-09-05 20:53 ` Andy Lutomirski 2018-09-07 19:53 ` Mauro Carvalho Chehab 0 siblings, 2 replies; 12+ messages in thread From: Justin Forbes @ 2018-09-05 20:34 UTC (permalink / raw) To: David Howells Cc: James.Bottomley, Peter Jones, joeyli.kernel, ksummit-discuss 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Ksummit-discuss] [TECH TOPIC] Kernel lockdown and secure boot 2018-09-05 20:34 ` Justin Forbes @ 2018-09-05 20:53 ` Andy Lutomirski 2018-09-05 21:01 ` Justin Forbes ` (2 more replies) 2018-09-07 19:53 ` Mauro Carvalho Chehab 1 sibling, 3 replies; 12+ messages in thread From: Andy Lutomirski @ 2018-09-05 20:53 UTC (permalink / raw) To: Justin Forbes Cc: James Bottomley, Peter Jones, joeyli.kernel, ksummit-discuss 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...] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Ksummit-discuss] [TECH TOPIC] Kernel lockdown and secure boot 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 2 siblings, 1 reply; 12+ messages in thread From: Justin Forbes @ 2018-09-05 21:01 UTC (permalink / raw) To: Andy Lutomirski Cc: James Bottomley, Peter Jones, joeyli.kernel, ksummit-discuss 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Ksummit-discuss] [TECH TOPIC] Kernel lockdown and secure boot 2018-09-05 21:01 ` Justin Forbes @ 2018-09-06 6:53 ` joeyli 0 siblings, 0 replies; 12+ messages in thread From: joeyli @ 2018-09-06 6:53 UTC (permalink / raw) To: Justin Forbes, Andy Lutomirski Cc: James Bottomley, joeyli.kernel, ksummit-discuss, Peter Jones, Andy Lutomirski 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Ksummit-discuss] [TECH TOPIC] Kernel lockdown and secure boot 2018-09-05 20:53 ` Andy Lutomirski 2018-09-05 21:01 ` Justin Forbes @ 2018-09-06 10:00 ` Jani Nikula 2018-09-06 10:05 ` David Howells 2 siblings, 0 replies; 12+ messages in thread From: Jani Nikula @ 2018-09-06 10:00 UTC (permalink / raw) To: Andy Lutomirski, Justin Forbes Cc: James Bottomley, Peter Jones, joeyli.kernel, ksummit-discuss 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Ksummit-discuss] [TECH TOPIC] Kernel lockdown and secure boot 2018-09-05 20:53 ` Andy Lutomirski 2018-09-05 21:01 ` Justin Forbes 2018-09-06 10:00 ` Jani Nikula @ 2018-09-06 10:05 ` David Howells 2018-09-06 10:21 ` Jani Nikula 2 siblings, 1 reply; 12+ messages in thread From: David Howells @ 2018-09-06 10:05 UTC (permalink / raw) To: Jani Nikula Cc: James Bottomley, joeyli.kernel, ksummit-discuss, Justin Forbes, Peter Jones, Andy Lutomirski 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Ksummit-discuss] [TECH TOPIC] Kernel lockdown and secure boot 2018-09-06 10:05 ` David Howells @ 2018-09-06 10:21 ` Jani Nikula 0 siblings, 0 replies; 12+ messages in thread From: Jani Nikula @ 2018-09-06 10:21 UTC (permalink / raw) To: David Howells Cc: James Bottomley, joeyli.kernel, ksummit-discuss, Justin Forbes, Peter Jones, Andy Lutomirski 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Ksummit-discuss] [TECH TOPIC] Kernel lockdown and secure boot 2018-09-05 20:34 ` Justin Forbes 2018-09-05 20:53 ` Andy Lutomirski @ 2018-09-07 19:53 ` Mauro Carvalho Chehab 1 sibling, 0 replies; 12+ messages in thread From: Mauro Carvalho Chehab @ 2018-09-07 19:53 UTC (permalink / raw) To: Justin Forbes Cc: James.Bottomley, Peter Jones, joeyli.kernel, ksummit-discuss 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2018-09-07 19:53 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-09-05 16:53 [Ksummit-discuss] [TECH TOPIC] Kernel lockdown and secure boot David Howells 2018-09-05 19:33 ` Jiri Kosina 2018-09-05 19:51 ` Justin Forbes 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
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.