Matthew Garrett <mjg59@xxxxxxxxxxxxx> writes: > On Tue, Sep 04, 2012 at 01:13:32PM -0700, Eric W. Biederman wrote: >> >> Matthew Garrett <mjg@xxxxxxxxxx> 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" <ebiederm@xxxxxxxxxxxx> >> >> 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-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
