113
Call of Duty and Battlefield 6 will both require Secure Boot on Windows
(www.theverge.com)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 06 Aug 2025
113 points (98.3% liked)
Games
20853 readers
472 users here now
Video game news oriented community. No NanoUFO is not a bot :)
Posts.
- News oriented content (general reviews, previews or retrospectives allowed).
- Broad discussion posts (preferably not only about a specific game).
- No humor/memes etc..
- No affiliate links
- No advertising.
- No clickbait, editorialized, sensational titles. State the game in question in the title. No all caps.
- No self promotion.
- No duplicate posts, newer post will be deleted unless there is more discussion in one of the posts.
- No politics.
Comments.
- No personal attacks.
- Obey instance rules.
- No low effort comments(one or two words, emoji etc..)
- Please use spoiler tags for spoilers.
My goal is just to have a community where people can go and see what new game news is out for the day and comment on it.
Other communities:
founded 2 years ago
MODERATORS
Can you really sign your own modified Windows kernel or drivers? I don’t think that’s how cryptography works.
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) is to use a shim binary and chain load into their own kernel binary. An exerpt:
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).
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?
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.
You mean this certificate? 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.
You can, but it probably needs a key related to Microsoft certificates