> This applies equally to the kernel command line, and given that we > cannot authenticate it, we should whitelist params that we know to be > safe, and filter out all others. A similar concern exists for the > device tree on ARM/arm64, and we already disable the DTB loader in the > UEFI stub if secure boot is enabled. Or you sign the boot command line. > > 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. > > > > In general, I think kernel hardening is an important topic It is - so pushing something with known trivial holes isn't a useful way to do this. The module parameter hole needs to be addressed before this is fit for upstream. 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
