Looks like it uses WinDivert as the filtering driver, which says on its site that "Windows Server 2016 systems must have secure boot disabled"; not entirely surprising and a reminder of what a lot of the "security" stuff is really securing.
"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.
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.
"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.
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.
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.
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.
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.
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.
