Whether it's a good idea aside You need to filter or lock down kernel module options because a lot of modules let you set the I/O port or similar (eg mmio) which means you can hack the entire machine with say the 8250 driver just by using it with an mmio of the right location to patch the secure state to zero just by getting the ability to write to the modules conf file. Without that at least fixed I don't see the point in merging this. Either we don't do it (which given the level of security the current Linux kernel provides, and also all the golden key messups from elsewhere might be the honest approach), or at least try and do the job right. Less security is better than fake security. If you've got less security your take appropriate precautions. If you rely on fake security you don't. The two other nasty cases you miss should be fine for x86 secure boot - but maybe not for secure boot in general. That is firmware loading and initial firewire state. Both should be fine on any 'secure' boot PC. Alan -- 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
