Hacker News Reader

Comment by buwrtgu | Hacker News Reader

"secure boot must be disabled" is the equivalent of "in case of permissions error, just chmod 777". secure boot literally protects the user first, and is configurable with user provided keys on the vast vast majority of open platform computers (i.e. amd64)

"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. there is no limitation of user rights because the user can turn it off and/or load their own keys at will.

secure boot fear mongering is bullshit nonsense

View on HN

secure boot literally protects the user first

No it doesn't. It's merely a convenient excuse to divert attention away from the truth, which is that it prevents users from doing things like defeating DRM and modifying the system to not be so hostile to themselves in other ways.

secure boot fear mongering is bullshit nonsense

Your position is the corporate propaganda.

Both are right -- is it so difficult to see that?

"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.

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.

Windows Server 2016+ with Secure Boot enabled won't allow loading of any third-party non-HLK-certified drivers, whether they are signed or unsigned. That's why.

And HLK is only for device drivers, not for any regular drivers, as far as I know.

Sad to see this downvoted without any response, because as far as I see he's exactly right.

No. That's just propaganda. The purpose is to further vendor lock you. MS has a minute share in the world of OS, completely outclassed by Linux. They're trying to force their way in by fooling people like you that something like Pluton is required.

The only reason they dominate the PC market share is because their spyware OS is installed by default and people don't go around switching OSes.

An anecdote about security; at my workplace, one of the top 5 security firms in the world, secure boot isn't required nor is MS. Makes you wonder.

I'm not sure if you don't know or don't want to know what SB does, but it's not propaganda, neither is it vendor-locking. Most widespread vendor locks don't use SB, neither is the functionality only usable for that (well duh, it could be, because you can choose your root of trust, but you can choose the root).

You might as well call other tech Linux doesn't play well with "vendor-locking" as this point with no concern, even if there are no real "locks" like that, just lack of support. "TME doesn't work? Literally vendor-locking and Microsoft propaganda!1!"

Security corporations, known for their cargo culting in addition to the usual corporate bullshit, aren't a great example. But bringing then up like they somehow were... makes you wonder indeed.

What? Secure Boot doing anything to force you into Microsoft solutions is a hardware vendor/supplier issue. They're the one that configure the secure boot parameters, and with minor exception (don't buy bad products...) they do not lock you out of booting non-Microsoft solutions.

I fail to see in any way how preventing the loading of unsigned drivers in the secure boot chain is "vendor lock-in".

Furthermore, that signature does _not_ have to be Microsoft's. You can sign a driver with a private CA and provided that signer is in the trust store, it will be loaded.

>at my workplace, one of the top 5 security firms in the world

Cool, my dad works for Nintendo tho. Agree with other poster, not sure if you even know what Secure Boot is. Seems like you read an article on Slashdot about it 10 years ago.

Reply on news.ycombinator.com