On 16 November 2016 at 23:27, One Thousand Gnomes <gnomes@xxxxxxxxxxxxxxxxxxx> wrote: > 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. > 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. > 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, and this series covers many cases where userland APIs can be subverted to manipulate the state of the kernel in ways that weren't intended. However, it would be naive to think that the series covers all such cases, and I don't think that is what the authors intend to convey. -- 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
