The privacy points in general are valid, but what irritates me is using this rationale against kernel mode anti cheats specifically.
You do not need kernel access to make spyware that takes screenshots. You do not need a privileged service to read the user’s browser history.
You can do all of this, completely unprivileged on Windows. People always seem to conflate kernel access with privacy which is completely false. It would in fact be much harder to do any of these things from kernel mode.
Actually, it is completely true. The TPM threat model has historically focused on software-based threats and physical attacks against the TPM chip itself - crucially NOT the communications between the chip and the CPU. In the over 20 year history of discrete TPMs, they are largely completely vulnerable to interposer (MITM) attacks and only within the last few years is it being addressed by vendors. Endorsement keys don’t matter because the TPM still has to trust the PCR commands sent to it by the CPU. An interposer can replace tampered PCR values with trusted values and the TPM would have no idea.
Technically yes, but it would produce an untrusted remote attestation signature (quote). This is roughly equivalent to using TLS with a self-signed certificate — it’s not trusted by anyone else. TPMs have a signing key that’s endorsed by the TPM vendor’s CA.
No, this is not true at all. Microsoft requires their system vendors (Dell, HP, etc) to allow users to enroll their own Secure Boot keys through their “Designed for Windows” certification.
Further, many distributions are already compatible with Secure Boot and work out of the box. Whether or not giving Microsoft the UEFI root of trust was a good idea is questionable, but what they DO have is a long, established history of supporting Linux secure boot. They sign a UEFI shim that allows distributions to sign their kernels with their own, distribution-controlled keys in a way that just works on 99% of PCs.
Well, this project is literally about me circumventing/removing Boot Guard so I don’t know how it’s corporate authoritarianism. I’m literally getting rid of it. In doing so I get complete control of the BIOS/firmware down to the reset vector. I can disable ME. To me, that’s ultimate freedom.
As a power user, do I want boot guard on my personal PC? Honestly, no. And we’re in luck because a huge amount of consumer motherboards have a Boot Guard profile so insecure it’s basically disabled. But do I want our laptops at work to have it, or the server I have at a colocation facility to have it? Yes I do. Because I don’t want my server to have a bootkit installed by someone with an SPI flasher. I don’t want my HR rep getting hidden, persistent malware because they ran an exe disguised as a pdf. It’s valuable in some contexts.
I have a slow burn project where I simulate a supply chain attack on my own motherboard. You can source (now relatively old) Intel PCH chips off Aliexpress that are “unfused” and lack certain security features like Boot Guard (simplified explanation). I bought one of these chips and I intend to desolder the factory one on my motherboard and replace it with the Aliexpress one. This requires somewhat difficult BGA reflow but I have all the tools to do this.
I want to make a persistent implant/malware that survives OS reinstalls. You can also disable Intel (CS)ME and potentially use Coreboot as well, but I don’t want to deal with porting Coreboot to a new platform. I’m more interested in demonstrating how important hardware root of trust is.
Calling it a “kill switch” buries the lede here. What these politicians call a kill switch is technology to passively detect drunk driving. In 2021, Congress passed a law (HALT Drunk Driving Act) requiring NHTSA to eventually require auto makers to install passive drunk driver detection systems. NHTSA missed their statutory November 2024 deadline to finalize the regulations on this so it’s not like this amendment failing has a substantial impact. This technology is still many model years (maybe 2029? 2030?) away. I make no claims to the merits of this technology, I just feel the need to clarify the current situation.
This is conceptually interesting to me because I see this as almost a more generic TI Webench. I’m curious why your focus in the sized “grid” blocks (presumably for placement directly on the PCB layout) instead of doing the same but for the schematic. That way I still have the flexibility of laying out the board how I want to meet eg mechanical constraints instead of working around a 12.7mm grid.
I’ve been paying for Google Workspace for my custom domain for years basically just so I can use Gmail. For just $7 more dollars a month, I upgraded my plan to access Gemini Pro, which has guaranteed enterprise-grade privacy controls. I think this is currently the best value platform for anyone who values their privacy for LLMs. If Apple and the DoD trust Google’s internal controls, I do too.
Because Red Hat pays the salaries of dozens (hundreds?) of kernel maintainers all over different subsystems. So they’re subject matter experts, and know exactly which ones are relevant to Red Hat.
I have an almost identical story except the state in question was Nevada. I’m curious what “dubious” domain it was, for me it was video game cheats. Maybe I’m actually the co-owner you’re talking about. :)
Checking version numbers usually isn’t a good way of determining whether software on Linux is vulnerable to CVEs. Big distros (especially Red Hat derivatives) lock software versions but back port security patches. Reporting “vulnerabilities” solely based on reported version number is pure noise.
I just want to point out that Windows actually has similar packaging problems. For some reason, Windows didn’t ship with C/C++/.NET runtimes. So practically every app ships with either a copy of the runtime DLLs or an installer to install those runtimes globally. Every Windows installation inevitably gets a million msvcrt dlls across random places, never getting any security updates. I believe this situation is a lot better on recent versions of Windows 10/11.
I sympathize with you and wish it was possible to support your situation and those similar situations like yours. It’s just disabling signature enforcement effectively removes a key security boundary between kernel and user space, something that that would just be too easy for cheats to exploit.
This is largely dependent on the passive collection capabilities of a particular anti-cheat. Sometimes getting a copy is useful to just to make 100% sure the detection you wrote works as intended. Sometimes it's because the techniques used are novel. Most anti-cheat vendors do this.
Secure boot addresses other specific security concerns that are unrelated to exploitable drivers. For instance, it eliminates a whole class of PatchGuard bypasses.
There’s nothing stopping you from using open source drivers, actually. Plenty of open-source projects like Dokan will typically run fine with an anti-cheat (ours will, certainly). What stops you from running a patched version is actually Windows itself, since Windows requires drivers to be signed with an authenticode codesigning certificate. Plenty of open-source projects and people have one, though. So it’s not an anti-cheat blocking you, it’s Windows itself. Of course, if you go out of your way to disable driver signature enforcement, most anti-cheats will prevent you from playing, but this is a mode strongly discouraged from Microsoft and does weaken your computer’s security.
You do not need kernel access to make spyware that takes screenshots. You do not need a privileged service to read the user’s browser history.
You can do all of this, completely unprivileged on Windows. People always seem to conflate kernel access with privacy which is completely false. It would in fact be much harder to do any of these things from kernel mode.