Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> wrote: > - The series conflates 'UEFI secure boot support' with 'kernel lock > down support'. I think this has been brought up before, but I really > think we should have a cleaner separation between the feature (locking > down various bits of the kernel if lockdown is in effect) from the > policy 'enable lockdown if UEFI secure boot is enabled'. I'm not sure what you're actually asking for. Are you wanting me to push the lockdown patches upstream separately from the UEFI patches that trigger the lockdown? Or do you mean something else? > The only tunable we need is in the lockdown context, whether lockdown needs > to take effect automatically when UEFI secure boot is detected So you don't want this change: config EFI_SECURE_BOOT bool "Support UEFI Secure Boot and lock down the kernel in secure boot mode" default n + select LOCK_DOWN_KERNEL but would rather have a separate option asking whether lockdown should be triggered if detect UEFI secure boot mode? > (but there could be other ways to enable lockdown, including a kernel > cmdline param or a sysfs node). A sysfs node is pretty pointless. A number of things that are locked down need to be locked down during boot. I could, however, provide a command-line option to engage it or a kernel config option to unconditionally enable it. > - The current series enables lockdown, but does not lock anything > down. Yes. As I pointed out, and as I'm sure you know, I have a slew of other patches that actually *do* lock things down. I extracted these patches to try and get some feedback on this bit without spamming various mailing lists with all the other patches each time. > Even if the code is in good shape otherwise, I am reluctant to > ack and/or merge anything right now, given that it provides a false > sense of security. You're a member of the "make it provably 100% secure or nothing" camp? > This also ties in to my more general concerns with this code (and I am aware > I never replied to your email explaining it, my apologies [again]): without > any sense of how large the attack surface is now, I suspect no one knows. I've been trying to lock down possibilities people have pointed me at, even if some of them are very theoretical, and a lot of the patches I've gathered together come from other people, but I don't know the hardware that a lot of this is dealing with, so I can't answer this question. > and how much we reduced it by implementing the items on your list above, we > should really not be making claims of security, given that we really have no > idea how much more secure we are. That said, I do subscribe to the effort, > in the sense that moving towards the goal is strictly better than moving > away from it, or not at all. Can we at least decide whether or not we want to put a locked-down mode into the upstream kernel? If not, I can drop this effort. David -- 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
