Hacker News Reader

"prevent injection of a driver that can divert all my shit at the kernel level" is exactly what you want secure boot protecting you from.

The only thing Secure Boot is doing here is preventing you from loading a driver not blessed by Microsoft. They would happily bless "a driver that can divert all my shit at the kernel level", but it costs too much for the maintainer of WinDivert.

View on HN

It is kind of sad that no one seems to bother enough to actually learn how to use Secure Boot to their advantage. Everyone is just disabling it the first time it gets in their way. Reminds me of how Firewalls used to be treated like 20 years ago. Yes, by default most implementations will only accept signatures from Microsoft. But the thing is: You can always enroll your own keys. My Laptop is currently booting a non-mainline Linux kernel with secure boot enabled. Just enroll your own Certificate and (automate the process to) sign binaries yourself. I really wonder why no one yet started some kind of project to provide a "community trust root" of some sorts which you could enroll on your machine.

I think that for the vast majority of threat models, the insecurity of having your own signing certificate (it needs to be hot if it's going to be automated) is not much different from the risk of not having secure boot at all. Also, the effort v. security balance.

Would it really help in this case? I believe the HLK-signing is enforced by Windows, not UEFI. Uploading your own cert to UEFI won't change that.

Reply on news.ycombinator.com