Valid concerns, but Secure Boot does not influence that outcome. The root access is the most egregious thing here, not Secure Boot.

I'm not sure about Windows specifically, I just know you can load your own keys onto the mobo. In general, a cryptographic signature is just metadata tacked onto a file, so presumably yes, you could sign the kernel yourself and load your key so Secure Boot works. The way Linux distros generally work (e.g. [Debian](https://wiki.debian.org/SecureBoot#What_is_UEFI_Secure_Boot.3F)) is to use a shim binary and chain load into their own kernel binary. An exerpt: > Starting with Debian version 10 ("Buster"), Debian supports UEFI Secure Boot by employing a small UEFI loader called shim which is signed by Microsoft and embeds Debian's signing keys. This allows Debian to sign its own binaries without requiring further signatures from Microsoft. So even if signing the Windows kernel doesn't work (I don't see why it wouldn't), you could use a loader shim like Debian does to not require loading your own keys. To be fair, I haven't read the details of Secure Boot specifically to know how it's done, I'm just going based on my understanding of PGP (about how signing works), early kernel boot, and high level details about Secure Boot. I'm sure someone sophisticated enough to design kernel-level game cheats could figure out how to make Secure Boot happy without a ton of effort from users. Secure Boot isn't designed to prevent users from doing things, it merely prevents malicious code from being loaded at boot (i.e. code that doesn't have access to the keys loaded onto the Secure Boot module).

You mean [this certificate](https://lwn.net/Articles/1029767/)? The one which will expire next year and leave many old machines with Secure Boot enabled, unbootable?

Unbootable w/o changes, yes, assuming hardware vendors actually respect the expiration date. But that's completely separate from my point. Regardless of the solution they pick for that particular problem, users can _still_ add their own keys to Secure Boot and do whatever they want.

They are using this to leverage their way into control over your system. They are trying to become the iOS of PC's, where you can't install or run anything Microsoft didn't collect protection money on.

You sound like you follow QAnon...

> I'm not sure about Windows specifically That’s quite an important omission because we’re talking about Windows. Windows won’t run kernel or driver that’s not using expected certificates, what would be the point otherwise?

How do you like your boot seasoned?

Come join the community I made recently specifically for battlefield like games made by indie developers such as the superb ww2 battlefield-like **Easy Red 2** ! !indiefields@sopuli.xyz

As a Bf3 and Bf4 player, I can count the number of cheaters I encountered on one hand. I won't buy Bf6 because they implement this shit instead of giving us self hostable community servers.

We still play UO every night. Historians have their Base Assault server going during the afternoons and there is usually a CTF and S&D server populated every night (which one it is varies) We’d love to have some old players back!

Again, I don't know the specifics about Windows, so I can't say exactly what a cheater could or could not do. I _do_ know that kernel chaining _does_ work w/ Windows, otherwise the GRUB bootloader would be DOA. Whatever Windows does is a completely separate thing from Secure Boot, since Secure Boot only impacts early boot (i.e. the handoff from UEFI to the kernel). So getting into what Windows does and does not allow isn't particularly relevant to the discussion about Secure Boot.

Get on Counterstrike, lads,