Re: [PATCH 07/11] kexec: Disable in a secure boot environment
On Wed, Sep 5, 2012 at 5:41 PM, Matthew Garrett wrote: > Yeah, I think renaming the cap is a given. CAP_RING_ZERO Needed for any activity which would give root the ability to run code in ring 0? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 07/11] kexec: Disable in a secure boot environment
On Wed, Sep 05, 2012 at 05:13:49PM -0400, Mimi Zohar wrote: > Normally capabilities provide additional permissions. So if you don't > have the capability, an errno is returned. CAP_SYS_BOOT is a good > example. With CAP_SECURE_FIRMWARE, it reads backwards - if not > CAP_SECURE_FIRMWARE, return error. I think you want to invert the name > to CAP_NOT_SECURE_FIRMWARE, CAP_NOT_SECURE_BOOT or perhaps > CAP_UNSECURED_BOOT. Yeah, I think renaming the cap is a given. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 07/11] kexec: Disable in a secure boot environment
On Tue, 2012-09-04 at 11:55 -0400, Matthew Garrett wrote: > kexec could be used as a vector for a malicious user to use a signed kernel > to circumvent the secure boot trust model. In the long run we'll want to > support signed kexec payloads, but for the moment we should just disable > loading entirely in that situation. > > Signed-off-by: Matthew Garrett > --- > kernel/kexec.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/kernel/kexec.c b/kernel/kexec.c > index 0668d58..48852ec 100644 > --- a/kernel/kexec.c > +++ b/kernel/kexec.c > @@ -944,7 +944,7 @@ SYSCALL_DEFINE4(kexec_load, unsigned long, entry, > unsigned long, nr_segments, > int result; > > /* We only trust the superuser with rebooting the system. */ > - if (!capable(CAP_SYS_BOOT)) > + if (!capable(CAP_SYS_BOOT) || !capable(CAP_SECURE_FIRMWARE)) > return -EPERM; > > /* Normally capabilities provide additional permissions. So if you don't have the capability, an errno is returned. CAP_SYS_BOOT is a good example. With CAP_SECURE_FIRMWARE, it reads backwards - if not CAP_SECURE_FIRMWARE, return error. I think you want to invert the name to CAP_NOT_SECURE_FIRMWARE, CAP_NOT_SECURE_BOOT or perhaps CAP_UNSECURED_BOOT. Mimi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 07/11] kexec: Disable in a secure boot environment
On Wed, Sep 05, 2012 at 05:43:08PM +0200, Roland Eggner wrote: > Jonathan Brossard: “… We have built a generic proof of concept malware for > the > Intel architecture, called 'Rakshasa', capable of infecting more than 100 > different motherboards. Targets are BIOS and firmware of PCI-devices. …” > http://www.toucan-system.com/research/blackhat2012_brossard_hardware_backdooring.pdf Neatly avoided by the relevant UEFI platforms requiring that all firmware be signed. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 07/11] kexec: Disable in a secure boot environment
On 2012-09-04 Tuesday at 22:40 +0100 Matthew Garrett wrote: > On Tue, Sep 04, 2012 at 10:39:57PM +0100, Alan Cox wrote: > > I think it needs to be defined in terms of what the capability is > > supposed to guarantee. I have a feeling Matthew has a pretty clear idea > > about that in his head so can nail it fairly precisely ? > > In the absence of this capability, all users (including root) should be > unable to cause untrusted code to be executed in ring 0. This requires > some straightforward and obvious conditions like "The user must not be > able to load untrusted modules", but also conditions like "The user must > not be able to cause devices to DMA over the kernel". "The user must not > be able to kexec into an untrusted kernel" is at the more obvious end of > the scale. This is obviously dependent upon there being some mechanism > for ensuring that the initial kernel is trusted in the first place, > which is where the firmware security comes in. You believe in firmware security? Not yet heard of “Rakshasa”? Reading [1] may change your mind. Want to support Erics technical arguments, given in another branche of this thread, by some “political” aspects: If I have payed for a device and then would not be allowed to use it due to some obscure “security” feature, this could perhaps be close to criminal. I am not a lawyer, can only guess. A few years ago a friend of mine bought an originally quite expensive, used notebook for just a few Euro. The seller was forced to do so, just because he added RAM and changed HD, causing activation of an unknown hardware password. It has been set by a retailer or the vendor, the latter being one of the largest players on the world market. Certainly I will never buy a device of this brand. If Linux mainline would really implement some kind of knock-out “security” feature, and would switch from GPL to another, for such a new policy more adequate copyright licence: it would be sad, but technically no problem, there are plenty of alternatives beyond penguins, windows and gates. Other users and contributors might follow … not good for the future of the Linux project. Better stick to the GPL and policy of freedom, then 20 years of aweful success on servers and embedded devices are more likely to continue or even to grow. [1] Jonathan Brossard: “… We have built a generic proof of concept malware for the Intel architecture, called 'Rakshasa', capable of infecting more than 100 different motherboards. Targets are BIOS and firmware of PCI-devices. …” http://www.toucan-system.com/research/blackhat2012_brossard_hardware_backdooring.pdf -- Roland Eggner pgploXjr1UcPT.pgp Description: PGP signature
Re: [PATCH 07/11] kexec: Disable in a secure boot environment
On Wed, Sep 05, 2012 at 12:00:31AM -0700, Eric W. Biederman wrote: > Matthew Garrett writes: > > Fine. We'll just carry this one out of tree for now. > > It is your tree. > > I am disappointed to learn that you aren't enthusiastic about > implementing verification of signatures for all code that goes into > ring 0. I am enthusiastic, but October 26th is a date outside my control and kexec isn't at the top of the priority list. We ship with the code we have, not the code we want. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 07/11] kexec: Disable in a secure boot environment
Matthew Garrett writes: > On Tue, Sep 04, 2012 at 09:33:31PM -0700, Eric W. Biederman wrote: >> Matthew Garrett writes: >> > The full implementation should trust keys that are trusted by the >> > platform, so it'd boot any kexec image you cared to sign. Or simply >> > patch this code out and rebuild and self-sign, or disable the code that >> > turns off the capability when in secure boot mode. I've no objection to >> > putting that behind an #ifdef. >> >> I will be happy to see a version of kexec that accepts signed images, >> allowing the functionality to work in your brave new world where >> everything must be signed. >> >> Until then I don't see a point in merging anything else. > > Fine. We'll just carry this one out of tree for now. It is your tree. I am disappointed to learn that you aren't enthusiastic about implementing verification of signatures for all code that goes into ring 0. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 07/11] kexec: Disable in a secure boot environment
On Tue, Sep 04, 2012 at 09:33:31PM -0700, Eric W. Biederman wrote: > Matthew Garrett writes: > > The full implementation should trust keys that are trusted by the > > platform, so it'd boot any kexec image you cared to sign. Or simply > > patch this code out and rebuild and self-sign, or disable the code that > > turns off the capability when in secure boot mode. I've no objection to > > putting that behind an #ifdef. > > I will be happy to see a version of kexec that accepts signed images, > allowing the functionality to work in your brave new world where > everything must be signed. > > Until then I don't see a point in merging anything else. Fine. We'll just carry this one out of tree for now. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 07/11] kexec: Disable in a secure boot environment
Matthew Garrett writes: > On Tue, Sep 04, 2012 at 03:12:52PM -0700, Eric W. Biederman wrote: >> Matthew Garrett writes: >> > The driving force behind this code right now is that our choices are >> > either (1) do something like this, or (2) disable kexec entirely. >> >> Actually there is an interesting question here. Why does even EFI secure >> boot justify this? If I install my own key in EFI I should be able to >> boot a kernel that does anything I want it to. My machine doing what I >> want it to is the point of trusted boot is it not? > > The full implementation should trust keys that are trusted by the > platform, so it'd boot any kexec image you cared to sign. Or simply > patch this code out and rebuild and self-sign, or disable the code that > turns off the capability when in secure boot mode. I've no objection to > putting that behind an #ifdef. I will be happy to see a version of kexec that accepts signed images, allowing the functionality to work in your brave new world where everything must be signed. Until then I don't see a point in merging anything else. I will be happy to see some reasonable patchs for signing support on the kexec path. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 07/11] kexec: Disable in a secure boot environment
On Tue, Sep 04, 2012 at 03:12:52PM -0700, Eric W. Biederman wrote: > Matthew Garrett writes: > > The driving force behind this code right now is that our choices are > > either (1) do something like this, or (2) disable kexec entirely. > > Actually there is an interesting question here. Why does even EFI secure > boot justify this? If I install my own key in EFI I should be able to > boot a kernel that does anything I want it to. My machine doing what I > want it to is the point of trusted boot is it not? The full implementation should trust keys that are trusted by the platform, so it'd boot any kexec image you cared to sign. Or simply patch this code out and rebuild and self-sign, or disable the code that turns off the capability when in secure boot mode. I've no objection to putting that behind an #ifdef. > > Like I > > said, long term we'd want to provide appropriate technical mechanisms to > > make kexec usable in a world where people want to be able to trust their > > kernel, and we have people working on that. But that being our > > motivation for the implementation doesn't mean that other parties won't > > have uses for it, and I'd like to find a solution that satisfies them as > > well. > > I expect you want to make that that medium term. Enterprise distros > don't ship without kexec-on-panic. Too often long term seems to be > something that no one ever gets around to in kernel development. I can't comment on the release schedule of unnanounced products or features that we may wish to be implemented in them. > > Sure it is. The kernel exists to provide the functionality that people > > require, and UEFI imposes that requirement on the people. It's like > > saying gcc policy shouldn't be the justification for kernel > > implementation details. We don't control the gcc developers, but we have > > to consume what they provide us with. > > This isn't efi specific code. We need to be able to think about what > is happening with a local analysis so we can see if it is correct. > > This is slightly violated already as pointed out elsewhere, > as CAP_SECURE_BOOT means we did not boot securely. If your problem is the naming, we'll change the name. Really not a problem. > > I'm afraid I have no idea what you're asking for here. Some vendors want > > to be able to ensure that kexec is only used to load trusted code. Right > > now there's no mechanism for ensuring that, so why not at least provide > > a mechanism for them to turn it off at runtime? > > There is a mechanism to turn it off at runtime CAP_SYS_BOOT. Which also prevents anyone from rebooting the system, which is really not what we're aiming for here. The firmware can enforce the booting of trusted code, the aim is to ensure that the kernel has equivalent functionality. > What I am asking for is a mechanism that makes sense without having to > think about EFI. Without having to think about the silly hoops people > are going through because of the impending launch of windows 8. Again, I'm not clear on what you're talking about here. There's nothing UEFI specific about this patch. Anyone who has firmware-level trust can drop this capability in order to make it harder for someone to circumvent that trust by replacing the running kernel at runtime. > I have the basic question, why can't I trust the root who has all > capabilities? What makes the root user more trusted than the linux > kernel. Especially when typically the root user is the owner of > the machine. Because historically we've found that root is also often someone who has determined a mechanism for running arbitrary code on your machine, rather than someone you trust. Root and the kernel aren't equivalent, otherwise root would just be able to turn off memory protection in their userspace processes. This patchset merely strengthens that existing dividing line. > There is a element here where it seems implementing the policy you > are proposing will start encouraging people to start hoarding kernel > bugs instead of reporting them. So implementing this policy might > make the kernel in net less secure. How is that prevented? It's not. The metric I'm concerned with says a kernel where root can load arbitrary code into the kernel is less secure than one where root can't do that. Implementing this functionality may result in some unfixed flaws that permit root to load arbitrary code. Not implementing this functionality *guarantees* that root can load arbitrary code. So, by the metric I'm concerned with, security improves. But security isn't a bright line subject, and other people may disagree. I can't force anyone to implement a given policy. > Ultimately the question is. > > This is Unix. In Unix we give root rope and let him hang himself > or shoot himself in the foot (not that we encourage it). > > Why are we now implementing a security model where we don't trust root? > > What is gained from a security model where root
Re: [PATCH 07/11] kexec: Disable in a secure boot environment
Matthew Garrett writes: > On Tue, Sep 04, 2012 at 02:13:54PM -0700, Eric W. Biederman wrote: >> Matthew Garrett writes: >> > And >> > secondly, there are already several non-EFI platforms that want to enact >> > a policy preventing root from being able to arbitrarily replace the >> > kernel. Given that people are doing this in the wild, it makes sense to >> > move towards offering that policy in the mainline kernel. >> >> Either this code makes sense without an appeal to EFI or this code makes >> no sense. > > The driving force behind this code right now is that our choices are > either (1) do something like this, or (2) disable kexec entirely. Actually there is an interesting question here. Why does even EFI secure boot justify this? If I install my own key in EFI I should be able to boot a kernel that does anything I want it to. My machine doing what I want it to is the point of trusted boot is it not? > Like I > said, long term we'd want to provide appropriate technical mechanisms to > make kexec usable in a world where people want to be able to trust their > kernel, and we have people working on that. But that being our > motivation for the implementation doesn't mean that other parties won't > have uses for it, and I'd like to find a solution that satisfies them as > well. I expect you want to make that that medium term. Enterprise distros don't ship without kexec-on-panic. Too often long term seems to be something that no one ever gets around to in kernel development. >> It is fine for jumping through the EFI trusted boot hoops to be your >> motivation, but EFI policy should not be the justification for kernel >> implementation details. > > Sure it is. The kernel exists to provide the functionality that people > require, and UEFI imposes that requirement on the people. It's like > saying gcc policy shouldn't be the justification for kernel > implementation details. We don't control the gcc developers, but we have > to consume what they provide us with. This isn't efi specific code. We need to be able to think about what is happening with a local analysis so we can see if it is correct. This is slightly violated already as pointed out elsewhere, as CAP_SECURE_BOOT means we did not boot securely. >> So please rework this to come from an angle that makes sense all by >> itself. > > I'm afraid I have no idea what you're asking for here. Some vendors want > to be able to ensure that kexec is only used to load trusted code. Right > now there's no mechanism for ensuring that, so why not at least provide > a mechanism for them to turn it off at runtime? There is a mechanism to turn it off at runtime CAP_SYS_BOOT. In general booting anything else besides what you are running is equally bad. What I am asking for is a mechanism that makes sense without having to think about EFI. Without having to think about the silly hoops people are going through because of the impending launch of windows 8. As Alan says a capability doesn't seem horrible. But if we use a capability it needs to be a well named capability, and the semantics of the capability need to make inherent sense. I have the basic question, why can't I trust the root who has all capabilities? What makes the root user more trusted than the linux kernel. Especially when typically the root user is the owner of the machine. There is a element here where it seems implementing the policy you are proposing will start encouraging people to start hoarding kernel bugs instead of reporting them. So implementing this policy might make the kernel in net less secure. How is that prevented? Ultimately the question is. This is Unix. In Unix we give root rope and let him hang himself or shoot himself in the foot (not that we encourage it). Why are we now implementing a security model where we don't trust root? What is gained from a security model where root is untrusted? Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 07/11] kexec: Disable in a secure boot environment
On Tue, Sep 04, 2012 at 10:39:57PM +0100, Alan Cox wrote: > > > Well, given that approximately everyone will be booting under EFI within > > > 18 months, treating it as a niche case seems a little short sighted. > > Actually the majority of Linux devices are not PCs 8) ARM's going UEFI as well... > I think it needs to be defined in terms of what the capability is > supposed to guarantee. I have a feeling Matthew has a pretty clear idea > about that in his head so can nail it fairly precisely ? In the absence of this capability, all users (including root) should be unable to cause untrusted code to be executed in ring 0. This requires some straightforward and obvious conditions like "The user must not be able to load untrusted modules", but also conditions like "The user must not be able to cause devices to DMA over the kernel". "The user must not be able to kexec into an untrusted kernel" is at the more obvious end of the scale. This is obviously dependent upon there being some mechanism for ensuring that the initial kernel is trusted in the first place, which is where the firmware security comes in. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 07/11] kexec: Disable in a secure boot environment
> > Well, given that approximately everyone will be booting under EFI within > > 18 months, treating it as a niche case seems a little short sighted. Actually the majority of Linux devices are not PCs 8) > > secondly, there are already several non-EFI platforms that want to enact > > a policy preventing root from being able to arbitrarily replace the > > kernel. Given that people are doing this in the wild, it makes sense to > > move towards offering that policy in the mainline kernel. > > Either this code makes sense without an appeal to EFI or this code makes > no sense. Yes - and the capability is I think the right starting point (although you'll never make any OS locked down this way even if you are not in fact violating the GPLv2 license by doing so, which I suspect will be the case for some implementations) > So please rework this to come from an angle that makes sense all by > itself. I think it needs to be defined in terms of what the capability is supposed to guarantee. I have a feeling Matthew has a pretty clear idea about that in his head so can nail it fairly precisely ? Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 07/11] kexec: Disable in a secure boot environment
On Tue, Sep 04, 2012 at 02:13:54PM -0700, Eric W. Biederman wrote: > Matthew Garrett writes: > > And > > secondly, there are already several non-EFI platforms that want to enact > > a policy preventing root from being able to arbitrarily replace the > > kernel. Given that people are doing this in the wild, it makes sense to > > move towards offering that policy in the mainline kernel. > > Either this code makes sense without an appeal to EFI or this code makes > no sense. The driving force behind this code right now is that our choices are either (1) do something like this, or (2) disable kexec entirely. Like I said, long term we'd want to provide appropriate technical mechanisms to make kexec usable in a world where people want to be able to trust their kernel, and we have people working on that. But that being our motivation for the implementation doesn't mean that other parties won't have uses for it, and I'd like to find a solution that satisfies them as well. > It is fine for jumping through the EFI trusted boot hoops to be your > motivation, but EFI policy should not be the justification for kernel > implementation details. Sure it is. The kernel exists to provide the functionality that people require, and UEFI imposes that requirement on the people. It's like saying gcc policy shouldn't be the justification for kernel implementation details. We don't control the gcc developers, but we have to consume what they provide us with. > So please rework this to come from an angle that makes sense all by > itself. I'm afraid I have no idea what you're asking for here. Some vendors want to be able to ensure that kexec is only used to load trusted code. Right now there's no mechanism for ensuring that, so why not at least provide a mechanism for them to turn it off at runtime? -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 07/11] kexec: Disable in a secure boot environment
Matthew Garrett writes: > On Tue, Sep 04, 2012 at 01:13:32PM -0700, Eric W. Biederman wrote: >> >> Matthew Garrett writes: >> >> > kexec could be used as a vector for a malicious user to use a signed kernel >> > to circumvent the secure boot trust model. In the long run we'll want to >> > support signed kexec payloads, but for the moment we should just disable >> > loading entirely in that situation. >> >> Nacked-by: "Eric W. Biederman" >> >> This makes no sense. The naming CAP_SECURE_FIRMWARE is attrocious, >> you aren't implementing or enforcing secure firmware. > > I'm certainly not attached to the name, and have no problem replacing > it. > >> You don't give any justification for this other than to support some >> silly EFI feature. Why would anyone want this if we were not booting >> under EFI? > > Well, given that approximately everyone will be booting under EFI within > 18 months, treating it as a niche case seems a little short sighted. If we are all going to be using the code we need to keep the code quality high. > And > secondly, there are already several non-EFI platforms that want to enact > a policy preventing root from being able to arbitrarily replace the > kernel. Given that people are doing this in the wild, it makes sense to > move towards offering that policy in the mainline kernel. Either this code makes sense without an appeal to EFI or this code makes no sense. It is fine for jumping through the EFI trusted boot hoops to be your motivation, but EFI policy should not be the justification for kernel implementation details. There may be some sense to the desired functionality. From what I have seen of the policies so far I have no respect for the way people are using EFI secure boot. I have no expectation that EFI secure boot will stop malware as long as anything signed by microsoft's key is trusted by the firmware. We have already seen malware in the wild that could be verified with Microsoft's key. So please rework this to come from an angle that makes sense all by itself. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 07/11] kexec: Disable in a secure boot environment
On Tue, Sep 04, 2012 at 01:13:32PM -0700, Eric W. Biederman wrote: > > Matthew Garrett writes: > > > kexec could be used as a vector for a malicious user to use a signed kernel > > to circumvent the secure boot trust model. In the long run we'll want to > > support signed kexec payloads, but for the moment we should just disable > > loading entirely in that situation. > > Nacked-by: "Eric W. Biederman" > > This makes no sense. The naming CAP_SECURE_FIRMWARE is attrocious, > you aren't implementing or enforcing secure firmware. I'm certainly not attached to the name, and have no problem replacing it. > You don't give any justification for this other than to support some > silly EFI feature. Why would anyone want this if we were not booting > under EFI? Well, given that approximately everyone will be booting under EFI within 18 months, treating it as a niche case seems a little short sighted. And secondly, there are already several non-EFI platforms that want to enact a policy preventing root from being able to arbitrarily replace the kernel. Given that people are doing this in the wild, it makes sense to move towards offering that policy in the mainline kernel. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 07/11] kexec: Disable in a secure boot environment
Matthew Garrett writes: > kexec could be used as a vector for a malicious user to use a signed kernel > to circumvent the secure boot trust model. In the long run we'll want to > support signed kexec payloads, but for the moment we should just disable > loading entirely in that situation. Nacked-by: "Eric W. Biederman" This makes no sense. The naming CAP_SECURE_FIRMWARE is attrocious, you aren't implementing or enforcing secure firmware. You don't give any justification for this other than to support some silly EFI feature. Why would anyone want this if we were not booting under EFI? Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
