(+ Kees) On 6 June 2017 at 09:34, David Howells <dhowells@xxxxxxxxxx> wrote: > Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> wrote: > >> and print a subsequent line for every lockdown feature that is enabled, e.g., >> >> lockdown: disabling MSRs >> lockdown: disabling hibernate support > > There's another problem with this idea: the lockdown facility is passive - it > doesn't go looking for things to lock down; rather, things that can be locked > down inquire as to whether lockdown is in effect at the point someone tries to > use them. > > Now, I could reserve a variable for each thing we lock down to make sure that > we don't emit the message more than once, but I'm loathe to waste memory this > way. > > I can't so easily switch the facility to being active either, since a lot of > the lockdownables are in modules. > Let me reiterate my concern for Kees's sake: without a threat model nor any notion of how much kernel lockdown reduces the attack surface, we end up with a 'doing something is better than nothing' approach. Fine. But now you are telling me that there is no way we can provide information to the user what that 'something' amounts to for a particular kernel build for a particular architecture. Do you intend to add lockdown features going forward after enabling the initial set? Would any of these lockdown features ever be Kconfigurable? Do you expect all lockdown features to be applicable to all architectures? So how do I know what lockdown actually means for my system? Anyway, I think I have made my concerns clear, and the EFI bits look fine to me as long as the policy lives elsewhere. Apologies for letting this drag on a bit. I do agree in principle, but I'd like to get the details right as well. Thanks, Ard. -- 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
