r/linux_gaming • u/cometomypartyyy • 23h ago
Why is Secure Boot still a huge point of contention in 2026?
After reading the recent updates about the Epic Games Launcher and Fortnite coming to Linux, I could understand the reasoning behind things like enabling IOMMU, blocking kexec, and even the trusted kernels + modules signed with a known key. (I'm not a fan since I sign my own kernels and modules, but I digress)
Although, I saw lots of replies on Twitter about people complaining about the Secure Boot requirement. Why? Maybe I've just gotten too used to the command line, but doesn't sbctl handle the key creation and the signing of the contents in the ESP well? And, I thought most user friendly distros automatically setup Secure Boot nowadays?
Regardless of your intentions to play video games with anti-cheats, I'd say that securing the early boot chain is something everyone should do.
79
u/dallenbaldwin 22h ago
As others have probably pointed out, I think it has more to do with the fact that Microsoft is still in the loop if you require Secure Boot because they're the ones managing it. I wonder if people wouldn't be as mad about it if there was a more distributed system in place.
21
u/EmmaRoidz 21h ago
I sure would like a better solution to the secure boot signing. Won't catch me dead with eBPF anti cheat tho.
11
u/Suspicious_Kiwi_3343 20h ago
Microsoft do not have to be part of secure boot at all. They signed shim purely because some Linux devs were scared people wouldn’t be able to follow instructions to load their own keys. There will almost guaranteed be ways of using this AC without any Microsoft key on your system.
7
u/tyler1128 15h ago
You can replace all keys with your own and self-sign. Just hope your hardware's firmware isn't signed with the microsoft keys as well.
4
u/Suspicious_Kiwi_3343 10h ago
You won’t be able to self sign for this as it’s a form of remote attestation.
Whether Microsoft has or hasn’t signed things is completely irrelevant, it’s not clear what you’re even suggesting. Anything that Microsoft could have signed relevant to Linux can also be signed by someone else and you can use their key instead.
→ More replies (5)1
u/tyler1128 9h ago
You remove the PK. The UEFI spec then requires you to be able to add KEKs that actually can modify the db and dbx entries.
5
u/Suspicious_Kiwi_3343 9h ago
Yes, you can’t do that for remote attestation. Using your own keys doesn’t provide any sort of trust that you aren’t cheating, obviously, so EAC will require you to use trusted keys and measured boot will tell them which keys were responsible for signing each part of the boot chain, so they know if they can trust you.
→ More replies (2)
21
u/gokufire 22h ago
People are talking about Arch and derivatives here but honest the situation is even worst on some distros based on Fedora or Ubuntu, like NobaraOS that is actively against Secure Boot (try their Discord or read their documentation) or PoPOS that requires to deactivate Secure Boot during installation and there are no easy way to use it reliably with upgrades.
1
u/Holzkohlen 12h ago
Yeah, but they may well change their stance on it now. What good is a gaming distro you can't game on, right?
2
u/gokufire 7h ago
It would be for sure a very big overhaul.
Nobara uses a patched kernel with several changes including using Apparmor instead of Fedora's standard SELinux. PoPOS similar, Cosmic requires newer rust libraries that aren't available in the end of life of Ubuntu's LTS releases. Those things makes very difficult to keep Secure Boot on, is not only ideology, if that is what you are thinking, there are technical challenges.
59
u/Complex_Aide4242 23h ago
Many distros such as Fedora do not automatically enable secure boot when installing Nvidia Drivers. Secure boot with Nvidia drivers is a pain as Fedora is not allowed to ship the proprietary drivers included in their distro and kernel (legally i think), which mean we Nvidia users will have to manually sign the kernel and hope the anti-cheat allows it.
11
u/LordAlfredo 20h ago
The signing is done by a self managed MOK cert, i.e. it can't possibly be on the allowlist. Only option is wait for Nova in-tree drivers to advance further (fortunately joint talk by Red Hat and Nvidia sounds like they're making good progress)
→ More replies (1)1
u/theevilsharpie 15h ago
The Nova driver is years away from prime time, and will never support GPUs older than the RTX 2000 series.
1
u/Indolent_Bard 7h ago
Valve said Nvidia support for SteamOS is coming 2027. They obviously were talking about the Nova drivers because they're not going to ship proprietary out of tree drivers.
Valve is personally contributing workers for this.
7
u/Suspicious_Kiwi_3343 20h ago
The kernel driver for modern Nvidia cards is open source not proprietary and fedora will sign their own build themselves. The user space drivers being proprietary doesn’t matter to this at all and isn’t relevant here.
4
u/tyler1128 15h ago
Part of the kernel driver for nvidia drivers is open soure.
nvidia-openas it is named on Arch is not fully open source, only the Linux kernel interacting part is.1
u/Suspicious_Kiwi_3343 11h ago
Can you point to the other part of the kernel driver that is not open source for modern Nvidia cards?
1
u/tyler1128 9h ago
All userspacee tools that interface with it, and the parts of the driver code, by their own repo, shared between operating system.
To quote its own readme:
This code base is shared with NVIDIA's proprietary drivers, and various processing is performed on the shared code to produce the source code that is published here. This has several implications for the foreseeable future:1
u/Suspicious_Kiwi_3343 9h ago
Right, so not kernel space drivers at all?
The kernel space driver is open source. The user space drivers are not. Only the kernel drivers need signing as part of secure boot. The fact that the kernel driver source is produced by processing applied to shared code that also produces proprietary drivers is completely irrelevant to secure boot, you only need to sign the thing the kernel loads.
→ More replies (11)5
u/cometomypartyyy 22h ago
I understand, thank you for the response. I thought that the whole Nvidia on Linux thing would be a lot smoother by now, but we definitely have a long way to go.
1
21h ago edited 20h ago
[deleted]
6
u/feckdespez 21h ago
But that would not work for EAC v2 which is the driver behind the current secure boot discourse. Obviously, it's possible to go the self signed route and get this all working. It's a solved problem.
But also explicitly not an option for this per Epic.
53
u/dumbasPL 10h ago
Because it's not secure boot for your security, it's secure boot for their security.
Secure boot is good when used with your own keys, nobody can boot anything not authorized by YOU on YOUR system. Absolutely recommend this, but this is not what they're talking about.
When used with the default Microsoft keys, it's not only not actually secure (vulnerable bootloader and other EFI binaries are still working, on ANY system, effectively bypassing the whole thing), but also you're limited to only what your distro gives you, want a proprietary kernel module? Better pray your distro signed it. Want a custom kernel because hardware is not supported yet upstream? Nice try. Want a different bootloader? Most of them don't even support secure boot and especially measured boot, not even talking about being signed by anybody.
3
u/returnofblank 4h ago
How is the bootloader insecure with Microsoft keys?
From what I remember of the process, the shim is signed by Microsoft, and the shim signs the bootloader and so on. I don't think it would be too different to use self-signed keys instead.
→ More replies (1)
25
u/tyler1128 20h ago
Microsoft being a single root point of trust to secure the process really means you need to trust microsoft's keys, and I can't say I trust microsoft. The Microsoft PK/KEK can be signed into device firmware too, so writing your own keys to the TPM and removing the MS keys without reflashing firmware on, say, GPUs, to replace the PK can literally brick your system, one of the relatively few ways to do so. My firmware also has 81 hashes of binaries forbiddden to boot all signed by MS's (now expired) Microsoft Corporation KEK CA 2011 KEK. Presumably they are there out of good intention, but given there's no real information, that's purely a presumption.
This is true whether you've ever had windows run on your machine at all. This is a desktop, not a laptop. I have a piece of PCIe hardware also containing that KEK as a signing key in its firmware binary.
10
u/Complex_Aide4242 22h ago
I'm also wondering how would drivers such as xpadneo work with EACv2. Im concerned it will not allow it as it is not from a major corporation. Xpadneo needs manual secure boot and key signing
3
1
u/rubberoidd 22h ago
Xpadneo is in tumbleweed repo
1
u/Complex_Aide4242 22h ago
does that work with the kernel without signing, and does the repo work with fedora?
2
u/rubberoidd 22h ago
No, it wouldn't, if you care about xpadneo driver and fortnite, you will have to move to tumbleweed, apparently.
2
u/friendlyreminder_ 13h ago edited 13h ago
No the kernel module has to be signed by the same key as the kernel. Opensuse signs the xpad Neo module themselves so it passes secure boot. It,'s just a regular package install, no manual signing needed. It'll work with their kernel, but no other.
You'd have to transplant opensuse's kernel, bootloader, and shim to have that work on fedora. It's much easier to just install Tumbleweed.
50
u/hackathi 15h ago
Secure boot (the principle) is very good to make _you_ able to keep _anyone_ out of your boot chain.
Secure boot (as implemented) is very good at making somewhat arbitrary third parties able to keep _you_ out of _your_ boot chain (and computer).
The discussion really ends at that. I will never play a game that requires me to enable secure boot; as implemented, it is a predatory scheme that puts control where control doesn‘t belong.
11
u/donewithdoing 10h ago
Exactly. A non-zero number of newbies try to switch from Windows to Linux, only to give up when Secure Boot being enabled blocks them from doing so. Microsoft knows this, and they love it.
4
u/zhulkgr25 12h ago
Exactly. Isn't microslop the ones who hand out the keys? They have a monopoly.
9
u/hackathi 11h ago
Nah, this is more complicated. In theory you can just roll your own PKI, sign your kernels, put your CA cert in your motherboard and be done. But this requires you to roll your own PKI, and keep it in good working order and secure.
What happened is that OEMs found out that people would pay them to include their CA in the mainboard. So companies like microsoft did; same as apple on their hardware when they still were x86. If you pay the OEMs enough money to have your certificates included, they most probably will. And at this point you are in the position to sign arbitrary boot programs (including kernels) and have them just work, because the required CA certificates are already distributed alongside the hardware.
So, with thankfully minor execeptions, it is still possible to roll your own secure boot keys. It's just extremely impractical at scale; which serves as plausible deniability: "No, we are not the bad guys, you see, you loosing control is a mere implementation detail".
Things like remote attestation (is my computer really running the software I want it to run?) are also fine in practice. However, because the most popular secure boot CA is controlled by Microsoft (because they can afford to pay OEMs to include their CA), in practice, remote attestation will turn to "Is this computer not running any software that $third_party does not like?".
This is unfixable but by regulation, barring the distribution of Secure Boot CAs with the Hardware.
7
u/TheRandomGuy75 22h ago
The only concern I have with secure boot is with things like Nvidia drivers. I mainly use Fedora, which requires you to manually sign the drivers and enroll a MOK key to use them with secure boot. My main desktop is an AMD machine thankfully which has no issues with it, but If I were on Nvidia, I'd want it to be easier to get Nvidia drivers signed before being ok with a secure boot requirement.
2
u/friendlyreminder_ 13h ago
Fedora will have to change how they ship the kernel driver as currently as you noted it is self signed.
Ubuntu and Opensuse already sign the Nvidia driver on their end so no self signing is needed. It'll work with the new EAC requirements in those distros.
Other distros like CachyOS will likely adopt this kind of signing too.
24
u/I-Use-Artix-BTW 22h ago
Some popular distros, particularly Arch and even CachyOS just don't come pre-signed.
A lot of people also view Secure Boot as a scam by Microsoft to lock-out Linux users. Debian's Wiki says it's not, though Rufus ran into problems with it because Microsoft decided that they won't sign GPLv3 software.
5
u/muffinstatewide32 18h ago
Maybe im dumb. But working with secure boot on fedora or arch is a pain in the ass. Unless its fedora with something that has an akmod.
I have no issue with secure boot. In fact i quite like a system that wont load code i didn’t tell it is ok. I dont like that microsoft seems to be the authoritative body on what can boot by default
But i also understand that the department that builds the things i hate about microsoft likely isnt the one signing keys for what i can boot.
I also dont like that this limits my software use on fedora as i cannot be bothered going though the signing process for virtualbox or vmware…. Not that i use those things anymore anyway.
Personally im pretty excited to see where this all goes with epic and their efforts.
I approve of how this behaves on paper and will be trying it out
6
u/Frosty_Complaint_703 15h ago
My suggestion, and ive also seen chatter about this is to break away from microsofy and form a non profit authority for signing etc.
The linux foundation itself seems a perfect candidate for such a signing authority. The authority needs to be non profit, with no monetary incentives,open and neutral etc etc
1
u/muffinstatewide32 15h ago
Precisely. Ive never considered it but i agree
2
u/Frosty_Complaint_703 15h ago
Or just scrap secure boot and design something better and then setup that authority based on that
1
u/TranquilAim 12h ago
If the Linux foundation was apolitical then yes, alas they are not and would likely hold back signage for distros and people they don’t like.
2
1
u/AgarwaenCran 13h ago
and on arch you need to come with your own keys for secure boot, which eac2 will probably not accept anyway.
25
u/prominet 22h ago edited 19h ago
To give some minor examples:
- Who decides what's to be signed and what not?
- What if keys expire and no one renews them, or if you don't update in time?
- Unique ID tracking.
- Custom kernel modules (nvidia drivers, for example).
- Tinkering with your kernel.
- No benefit to AC (it does not help with detection of what you do, as in if you're cheating, only if you have something unsigned, which will not be cheats in 99.999% of cases).
- .edit: also, changing your hardware, like adding a new disk or switching CPU, can brick your installation.
2
u/friendlyreminder_ 13h ago
The distro decides what's signed.
Microsoft has developed an update method for updating the keys without a vendor bios update needed, so they can often be updated even if your bios no longer gets updates from your vendor. If you don't update in time you just turn secure boot off temporarily and then update them. It doesn't lock you of the OS.
The TPM remote attestation does track your TPM but it's not like they don't already scrape all your hardware ids with other methods.
Kernel modules can be signed and distributed by the distro themselves. Opensuse and Ubuntu already do this for nvidia.
Adding new hardware doesn't brick anything.
→ More replies (5)2
u/Suspicious_Kiwi_3343 20h ago
The distro
The key won’t expire. If it has expiry date or needs to be changed, go add the new one?
What unique id?
Signed by the same key that is approved by EAC. So you’ll need to get the fedora key, add it to BIOS, it will work fine. Some kernel drivers that won’t be signed by the distro maintainers won’t be usable if you want to use the AC, so you’ll need to unload them or maybe restart PC before playing.
If you tinker with kernel, you’ll need to untinker before playing. A custom kernel cannot be trusted for a competitive game, obviously.
If they use LSM eBPF it will definitely help them stop cheaters. Even just the remote attestation would make a big difference. Detecting unsigned kernel modules is exactly how they stop you from having a process modifying or reading memory it shouldn’t.
9
u/prominet 19h ago
The key won’t expire.
Microsoft's own keys expired recently. They were valid 15 years. Sure, microsoft provided new keys (which a lot of people still did not update and had their systems bricked), but what if they didn't? What if some niche distro does not?
Signed by the same key that is approved by EAC.
Who decides what EAC approves? And what if they suddenly decide to no longer approve something? All EAC games may stop working at their whim (and not only theirs), even if you comply.
What unique id?
Enabling TPM generates a unique ID that makes your PC super easily traceable (riot uses this ID to perma ban PCs). It's similar with secure boot.
A custom kernel cannot be trusted for a competitive game, obviously.
What about non-competitive games, like back 4 blood coop or space marine 2?
Detecting unsigned kernel modules is exactly how they stop you from having a process modifying or reading memory it shouldn’t.
Except the point is to detect cheating, not modifications to your system. You can run a million non-cheats in your unsigned modules, and it shouldn't matter whatsoever unless you are actually cheating.
1
u/Suspicious_Kiwi_3343 10h ago
Then don’t use that distro? What exactly is your argument? They can’t brick anything, just turn off secure boot to boot into the exact same environment you were using before, recover all your data, and set up a new secure boot environment if you want to carry on using your system for things that require remote attestation? If the distro you’re using sets up key expiry and then doesn’t replace the keys when they expire, then you’re going to need to trust a different 3rd party for your keys because they’re incompetent.
EAC decides? And if they want to not trust certain machines accessing their game servers and ruining their games for all the other players, that is their choice. Financially they have a huge incentive to make it as compatible as reasonably possible to make their desirability as an AC as big as possible. If they start reducing their own market share by blocking common setups, the gamers won’t be able to play, and the game devs will lose money and stop using it.
HWID is already an issue whether you use TPM or not. There are privacy concerns here but without a way of banning people cross account, the AC is useless for any free to play game like Fortnite.
If non competitive games are using a KLAC then that’s the choice of their devs. Not sure why they would pay to use a service for a game that doesn’t need it. If the games aren’t using it, you’ll be able to play on any kernel.
They detect cheating by monitoring what modules you’re using. Custom modules for DMA devices can be banned, modules for DMA through software will be banned. They had two choices, either prevent modification and use remote attestation to guarantee a trusted client, or massively escalate their privilege and monitor everything you’re doing on your PC and decide whether the modifications you use are worth banning you for. They chose the less invasive option.
1
u/prominet 4h ago
HWID is already an issue whether you use TPM or not.
Basic HWID is easy to spoof, and while you could argue that spoofing it while playing online games would somehow be wrong, you could spoof it for other reasons. Spoofing PCR with TPM enabled is much more difficult, and it is accessible to anyone at any time.
without a way of banning people cross account, the AC is useless
So, you think hardware bans are ok? Killing the entire 2nd hand market, and so on? I'd rather have to send them my government ID to be able to play (I don't, but it would be better than hardware bans); I'd simply not play f2p games. This is an issue they created.
If non competitive games are using a KLAC then that’s the choice of their devs.
Sure. I don't have to like it, though.
They detect cheating by monitoring what modules you’re using.
The problem is, they don't. They only detect that you have some unsigned code. They don't know what it does. Sure, it might be more private than scanning everything that's running on my device, but that's not how they should be doing it either. AC should be on the server-side, checking if what you're doing is legitimate.
1
u/Suspicious_Kiwi_3343 4h ago
It does suck for privacy but I don’t see how they’re meant to avoid it if they want a working anticheat, without TPM you have no way of trusting the client at all.
HWID bans exist because of the privacy concerns of having to send in your ID to get an account. The small number of people it affects in the 2nd hand market is better than making it trivial for people to bypass bans. Games that use them clearly have way less cheaters than games that don’t.
The problem is server side AC doesn’t work well for a lot of games. Most FPS games can’t be protected by purely server side AC, it’s not a matter of simply checking if a user has permissions to do X or Y, it becomes very complex when you need to check whether the inputs and events you’re being told happened by the client are completely legitimate from a permission perspective, but might be completely impossible from a human perspective. You have to write software to try and somehow figure out whether the things the client is claiming happened are possible for a human to do based on what you consider reasonable in terms of coordination, timing and game sense and that generally leads to statistical approaches that fall apart quickly because performance is so incredibly random and sometimes people just get outrageously lucky. Nobody has managed to make a purely server side AC work for this, even with extensive statistical analysis it just isn’t accurate enough to account for dumb luck, or a bad network connection leading to dropped packets making inputs look suspicious etc.
The other thing people suggest is often just hiring more employees to manually review games, but this clearly doesn’t scale when you have millions of games played per day. Even using a statistical model to filter that down to “suspicious games” you still have thousands of games to review every day and an employee can’t process many games per day, while needing special training because reviewers won’t even be able to understand how or why players are able to be so good at high levels without training, and now you need courses for training that somehow keep up to date with meta etc. As someone who was once very good at a game, I would never trust a manual reviewer to judge my gameplay because they’d have needed to be a top 0.1% player to understand my decision making.
People massively underestimate how complex stopping cheaters in these games is, and it’s clear that some basic level of trust in what the client is running is massively beneficial. Anyone who’s played CS2 and faceit has experienced the difference between the game being completely unplayable, and mostly cheater free, purely because of client side AC. No server side AC has gotten close to those results, it’s simply inhumanly complex to build such an accurate statistical model.
1
u/prominet 2h ago
The problem is server side AC doesn’t work well for a lot of games. Most FPS games can’t be protected by purely server side AC, it’s not a matter of simply checking if a user has permissions to do X or Y, it becomes very complex when you need to check whether the inputs and events you’re being told happened by the client are completely legitimate from a permission perspective, but might be completely impossible from a human perspective. You have to write software to try and somehow figure out whether the things the client is claiming happened are possible for a human to do based on what you consider reasonable in terms of coordination, timing and game sense and that generally leads to statistical approaches that fall apart quickly because performance is so incredibly random and sometimes people just get outrageously lucky. Nobody has managed to make a purely server side AC work for this, even with extensive statistical analysis it just isn’t accurate enough to account for dumb luck, or a bad network connection leading to dropped packets making inputs look suspicious etc.
I agree. Which is why those AC companies should focus on making it work, instead of playing this cat and mouse game with more invasive client-side tools that will never be able to do what they're supposed to.
The other thing people suggest is often just hiring more employees to manually review games, but this clearly doesn’t scale when you have millions of games played per day.
Why hire people? Just pay users to do it with in-game currency, skins, etc. It'll be free and also get more people to interact with the game. It used to work great back in the day.
No server side AC has gotten close to those results, it’s simply inhumanly complex to build such an accurate statistical model.
AI wrote a clone of adobe suite from spec. Epic used AI to write their new client. There's some good use for "inhumane" tech right there.
without TPM you have no way of trusting the client at all
You can't trust client with or without TPM. And TPM is too much of a danger to have it enabled just to play a game.
1
u/Suspicious_Kiwi_3343 2h ago
The companies can’t improve it. I don’t know how much programming you’ve done but what you’re describing is practically impossible because there is nothing about the games inputs that are “wrong” or bad in anyway, they have to use statistical methods, and by the nature of statistical methods, there is always a chance of being wrong, either too lenient or too strict. For some games server side works great but games like CS have had decades of server side ACs, statistical models etc and none of it got even close to being good enough.
The problem with using users is that the users can submit bad information, so groups set up bot farms to feed the AC incorrect data while farming the skins. Even when you limit it to a trusted group of players, those players are way too few in number to process all the reports being made, and they aren’t good enough at the game to accurately judge high level gameplay.
AI anti cheats are definitely going to be interesting, but AIs are still just statistical models and they suffer from the same flaws as any other statistical methods, when outliers happen they make bad decisions.
Using a combination of TPM, secure boot, measured boot and IOMMU you can absolutely trust clients way more. You know they must be running a certain OS, kernel, you can verify boot chain, and using IOMMU and driver signing you can prevent DMA devices. Of course there are some ways around it for people creating custom hardware, but the vast majority of people cannot bypass this and it verifiably works. It also raises the price of entry to cheating to be so high, that when you do get caught by a manual review or statistical model, you can’t afford a new account because you’d need an entire new computer with the same custom hardware and a new DMA device. Almost nobody has enough motivation to justify those costs, both financially and in terms of time and effort to learn everything involved and get it set up.
These ACs have been used for years in valorant and faceit, and the amount of cheaters there is like 1 per 100 matches rather than more than 1 every single game in normal CS2 matchmaking. It’s genuinely the difference between a playable game and a completely unplayable one.
1
u/prominet 1h ago
they have to use statistical methods, and by the nature of statistical methods, there is always a chance of being wrong, either too lenient or too strict.
So is banning people based purely on the fact that you have an unsigned kernel/kernel module. They don't care if you cheat or not, they don't even have tools to check if you are. I'd rather have people banned for performing outside of human possibilities and let some subtle cheats pass (which I'm not saying is acceptable), than to have people banned for running an unsigned headphones driver.
1
u/Suspicious_Kiwi_3343 43m ago
They aren’t banning people for that, they’re preventing people from loading it in the first place. Yes, unsigned drivers won’t work and people will lose functionality while playing the games, but as long as they retain the ability to disable the restrictions when they aren’t playing the game that seems a reasonable trade off.
Also, it seems they will have some tools to see whether you are cheating by using LSM eBPF with these secure boot restrictions.
→ More replies (0)5
u/tyami94 17h ago
yea but a pci-e dma device makes working around your last point very trivial. can even theoretically plug them in over thunderbolt, further reducing the barrier to entry. this is the method basically all cheaters use nowadays and it more-or-less entirely defeats the whole cryptographic chain-of-custody thing they're going for.
4
u/Kurumi78 15h ago
"It doesn't stop every last cheat so it is completely worthless" how about getting rid of 95+% most people will encounter. It's much harder and more expensive to get a dma cheat going. Increasing the barrier to entry will stop a lot of people.
Sure it won't stop Joey McClosetPro over there but it will stop little Timmy.
And there are many more little Timmy's than Joey McClosetPros.
It takes it from "download a free cheat" or "Drop $20 on a kernel level cheat" to "Buy an expensive device. Open up my pc, and install something." That's a lot higher bar.
1
u/Suspicious_Kiwi_3343 10h ago
Cheats that work that way are expensive and annoying for the average gamer to set up.
Anyone who has played games like CS, know that these measures make a huge difference. Without KLAC, you’re going to get more than one cheater per game at high elo. On faceit using KLAC, you get one cheater every 50 games maybe? It’s such a ridiculously pronounced difference.
Also, the dma device needs drivers to run. Lots of games have made it very difficult to use now as the KLAC can check if you have drivers loaded for these devices. On Linux I imagine those dma devices would require a kernel module that this AC would be able to stop, so it’s definitely not as trivial as just plugging the device in and your cheats instantly work, you’ll need to load a driver without the AC knowing, meaning the driver needs to be signed by an approved party and the measured boot will record what you loaded so the AC would be able to stop this in most cases.
1
u/tyami94 8h ago
it turns out i was wrong, but not for the reason you are saying. its because eac v2 requires iommu to be enabled, which pretty thoroughly breaks dma devices.
outside of that, you are incorrect. i'm pretty sure dma devices *do* have to announce that *a* pci device is attached, but they dont have to be honest, and they dont need a driver either. the pci device they announce to the system is just a dummy device to get its "foot in the door". after the system enumerates it, it can read and edit whatever memory it wants to because it is operating at a much lower level than any software on the machine (including the kernel).
1
u/Suspicious_Kiwi_3343 7h ago
The driver is required because of IOMMU, but you’re right I didn’t explain that properly.
→ More replies (1)1
u/Frosty_Complaint_703 15h ago
I imagine, and this would be huge, that epic will generally work with nvidia to improve drivers because of this, which is a win for all of linux
1
53
u/WMan37 22h ago
"Linux is about freedom
Unless you want to use a distro with a modified kernel, such as the extremely popular CachyOS, or be 100% free of microsoft but be forced to use secure boot central trusted authority that is microsoft, who, on a whim, can decide 'I don't want linux users to have access to EAC anymore' and then not approve the keys."
Also even for fedora users if they use nvidia unless fedora makes a one click "sign the keys" process it's just another barrier for the average user. This whole thing feels like honey laced with poison.
In some ways, this is actually worse than if epic did literally nothing and just never let fortnite run on linux.
4
u/Wooloomooloo2 14h ago
Given the entire Azure plant runs on Linux, Microslop are hardly about to pull the plug on its ability to boot.
19
u/Suspicious_Kiwi_3343 20h ago
That’s not how secure boot works. Microsoft can’t do that, it’s not a central authority at all it’s actually entirely decentralised you choose what keys you use.
-5
u/tyami94 17h ago edited 6h ago
that is not a guarantee. custom keyrings can very easily be taken away, and microsoft made a point to explicitly disallow them on the early arm systems because that was the status quo. frog boiling 101
edit: google this before you downvote. official microsoft docs from when this happened: https://download.microsoft.com/download/7/0/e/70e74967-b0fe-477a-974f-c1ed16ee31df/windows8-1-hardware-cert-requirements-system.pdf (see page 114, pt. 17C and 18)
1
u/Suspicious_Kiwi_3343 10h ago
Custom keys can only be stopped by BIOS manufacturers. They can’t easily be taken away at all, you’d need to go and flash your BIOS, and the manufacturer would need to want to make that change which they stand to gain nothing from.
It’s not clear which early ARM devices you’re talking about, but it seems you’re talking about Microsoft’s own hardware being set up to use secure boot with Microsoft keys? I’m not sure how you think that is equivalent to them preventing secure boot with custom keys across all ARM devices.
4
u/tyami94 8h ago
this is untrue. in order for pc hardware to be "certified for windows", x86 platforms were *required* to ship with microsofts keys and early arm platforms (like devices similar to surface rt) were *required* to force secure boot on and not allow custom keys.
if they thought they could get away with it, microsoft could very easily enforce the same requirements they tried to force on arm on x86 too.
1
u/Suspicious_Kiwi_3343 7h ago
Hardware manufacturers ship their own set of keys, and include the Microsoft KEK and DB keys. What I said about custom keys only being stopped by the BIOS manufacturer is correct, and it would require flashing your BIOS to change the current behaviour of your UEFI where you can manage the keys yourself.
Shipping Microsoft keys doesn’t mean Microsoft is in control of secure boot entirely on your motherboard, that’s not how secure boot works. It just means they can sign boot objects and your UEFI will consider them verified and secure. You can remove the Microsoft keys whenever you want, it’s simply shipped by default to make it easier for the average user, and to get the certified by windows marketing badge.
I can’t find any evidence they tried to force it on all ARM devices, the surface RT is a Microsoft product with a locked down BIOS. Secure boot is enabled because it’s good security practice, and considering it’s a Microsoft product they obviously pre loaded Microsoft keys for windows to work. Yes the BIOS is locked down for that specific product, but that’s their own product.
2
u/tyami94 6h ago edited 5h ago
i am acutely aware of how secure boot works. look at my other comments. the issue is that they're raising the bar and christening "certified" linux distros. this is gonna lead to an android situation where they boil the frog, and then when only a small amount of people will notice they'll flip the switch to enforce secure boot and eliminate custom key management because its obviously in microsoft's best interest to do so.
it's not like you can patch uefi firmware anymore on modern systems. intel boot guard makes it impossible (except on older generations with buggy implementation, also not sure if this is the case w/ amd). modern bioses also implement rollback protection much of the time now, so you can't revert to older firmware unless you're willing to break out your ch341a and do it yourself the old fashioned way. (dont know if this is the case on cots atx boards, but on most pre-builts and laptops this is something you can at the very least opt-in to)
i've also encountered motherboard oems that sign their firmware, which means breaking out the ch341a if you want to modify things. i know the asrock x370 boards did this at the very least, and even though its not backed by any form of hsm, its still another barrier to running your own software on a thing that you bought and paid for.
i can't find any evidence...
it *was* intended to apply to third parties, but windows rt sucked so there really weren't any. microsoft specifically made secure boot mandatory on arm, and explicitly mandated that custom mode was not allowed. see page 114, pt 17C and 18 here: https://download.microsoft.com/download/7/0/e/70e74967-b0fe-477a-974f-c1ed16ee31df/windows8-1-hardware-cert-requirements-system.pdf
1
u/Suspicious_Kiwi_3343 5h ago
But how do you think they will flip the switch? By what technical means will they be able to do that? The users will still be able to go into their UEFI and modify keys, sign their own boot objects etc. I’m not seeing where the jump is between approving certain Linux kernels for gaming, and somehow removing custom keys from your UEFI and forcing you to use their keys with secure boot force enabled. The UEFI manufacturer would have to agree to remove the options for secure boot and custom keys, and I don’t see how this change would lead to them agreeing to that.
That link seems to suggest to me that Microsoft wanted windows 8.1 to require secure boot and no custom keys, but the manufacturers completely ignored them so it kind of backs up the idea that Microsoft really don’t have the control or influence to force this on everyone, never mind epic games somehow having that much influence. If epic games trust keys from many vendors, like fedora, Ubuntu, Microsoft etc then this could potentially even reinforce that people need the control over their keys rather than allowing secure boot to get centralised to just one vendors keys.
I get the theory of why it’s concerning but I don’t see how it would ever play out in reality I guess.
3
u/tyami94 5h ago edited 5h ago
But how do you think they will flip the switch?
the same way they always have. by making new things that dont support it anymore with new security "features" that eventually become "required" thereby rendering the old hardware useless. look at android (or even windows 11) for examples of this.
the oems *have* to agree if they still want their hardware to be "certified for windows". if the oems dont play ball, then they are cutting themselves off from supporting and shipping with the most popular OS in the world. its been this way since the 90s and its a big reason why microsoft was sued for anti-trust.
they backed off a little bit after that, but they've been slowly moving back to old habits if you've been paying attention. microsoft literally has the power to add new useless hardware buttons to your keyboard, what makes you think they cant implement tighter software controls?
That link seems to suggest to me that Microsoft wanted windows 8.1 to require secure boot and no custom keys, but the manufacturers completely ignored them...
then you didn't actually read it. it was only disallowed on *ARM*. there wouldve been hell to pay if theyd done it on x86, but they could get away with it on ARM because that was already the status quo.
the manufacturers that made windows ARM devices *could not* ignore them if they wanted to be allowed to make those devices. there were several windows RT tablets made by third parties outside of the surface RT, and *ALL* of them had these restrictions due to *that* document i just linked you. https://windows-rt-devices.gitbook.io/windows/general/windows-rt-devices
there is absolutely nothing stopping them from doing this again if they think they can get away with it, and it is in their best interest to do so because it would be the only way they could maintain control over the PC platform.
If epic games trust keys from many vendors, like fedora, Ubuntu, Microsoft etc then this could potentially even reinforce that people need the control over their keys rather than allowing secure boot to get centralised to just one vendors keys.
you are ignoring how important ease of access is. if the easiest approach is to use a microsoft-signed shim, then that is what *everyone* who isnt a nerd like you or I will do. if the vast majority are using microsoft shims, then that means microsoft will still have defacto control over the platform and could absolutely enforce their will.
16
u/Historical-Bar-305 20h ago edited 13h ago
If Linux is freedom, then it is completely fine with the spirit of freedom, this case gave you the freedom of choice if you want to play Fortnite, follow these security requirements or just don't play Fortnite. Previously, there was no choice because game doesn't work in both scenarios with secure boot or without, but now we have a choice. So yeah this is a freedom play or not play Fortnite on linux.
19
u/WMan37 17h ago
I'm not worried about fortnite, I'm worried about existing games I already bought and enjoyed playing updating to EAC v2 and locking me out for using cachy.
→ More replies (1)2
u/ericek111 15h ago
.. and that's how you rid yourself of freedom.
2
u/Historical-Bar-305 14h ago
If you cant play Fortnite on linux its not because of freedom its because a lack of freedom. Peoples on linux have a choice you can play just do our recommendations or just dont play, its better than earlier when linux was restricted at all. This is acrually a freedom.
-1
u/ericek111 13h ago
Yeah, "just do our recommendations", like until now, use Windows. Except now we're shifting the goals, and it's "use the specific Linux distributions we have approved". And if your system (or you) needs a specific kernel module that isn't shipped with your corporate-approved kernel, well, tough.
2
u/Historical-Bar-305 11h ago
Bro are you read what a logic of this Anti-cheat? There is no any kernel modules (only standard protection linux features) just systemD service and eBPF with secure boot and tpm.
1
u/Salander27 8m ago
There's nothing stopping a distro from having any third-party kernel module (like the Nvidia one) in their repo and then signing them with the same key used to sign the kernel. You just won't be able to use DKMS or similar to build those modules yourself.
-1
u/Historical-Bar-305 14h ago
Why ? Yo can trun off this and change the kernel and dont play Fortnite you will have your freedom back.
4
u/ericek111 13h ago
You can just boot into Windows, there, solved... Are you really that blind? It starts with Fortnite, and soon you won't be able to use an out-of-tree kernel module if you want to play multiplayer anything. But murr hurr, you can just use a Tim® approved kernel!
It's completely antithetical to Linux philosophy. It's like Play Integrity on Android. Hey, you can freely choose to just not use your banking apps, NFC payments, some social media apps.
3
u/_sLLiK 8h ago
Agreed. The moment this becomes an accepted solution, all new games leveraging EAC 2.0 will be unplayable on Linux except for 5 approved distros. There's the possibility that some older games still being actively supported could have the EAC version they rely on updated as well. This is actually a step backwards.
3
u/xdominik112 18h ago
True, frog boiled really well it seems
M$ failed UEFI (and secureboot) attempt to control PC marker is finally paying back. Kernel level anticheat is really root of all devils.
Not like linux ecosystem is better cought cought systemd but lets not start that discussion
→ More replies (2)-7
u/Navarrog_01R 21h ago
But you can. Just keep one kernel for gaming and another that you’ve modified, you wouldn’t even need a dual boot.CachOS or Arch will eventually have to start signing their kernels and engage with Epic to get them recognized.
2
u/tyami94 17h ago
i sincerely hope that they do not do this. these are outrageous requirements.
1
u/Navarrog_01R 17h ago
Is requiring a kernel signature an absurd demand? How else could they guarantee that the kernel has not been modified by some malicious program?
3
u/tyami94 17h ago
requiring a kernel signed *by microsoft* is absolutely an absurd demand. the point is not to ensure that malicious programs arent modifying things, they couldn't give a shit about that as evidenced by the unbelievably shitty drivers that microsoft has signed in the past (see the nasty attacks that were made possible by genshin impact's anti-cheat, for example).
the point is to make sure *you* aren't modifying things. this is a slippery slope to a world where only msft-signed kernels are useful for anything, just like what has happened to android. i personally use and rely on features that they are demanding be disabled, like kexec.
1
u/Frosty_Complaint_703 15h ago
And therefore i have seen chatter of people saying of opening up such a non profit organisation within the linux foundation. That seems to be the perfect choice. Open , decentralized and neutral
1
u/Navarrog_01R 17h ago
What do you mean, "mandatorily through Microsoft"? I know that the vast majority of motherboards have their bootloaders certified by Microsoft, but the kernel of a Debian or Fedora system shouldn't need to go through Microsoft approval, right? Where did I misread this?
1
u/tyami94 16h ago edited 16h ago
at one point i was freelancing as an embedded hw/sw engineer, and i have had to implement my own uefi support for hardware that i designed before so i actually have insight here.
put simply, while not explicitly stated by epic, allowing people to self-sign their own kernels (which is a very good idea that i am extremely supportive of) would not prevent the class of attacks that anti-cheats are trying to stop. people could just make a kernel that lies to the anti-cheat and sign it themselves, rendering it pointless from the pov of epic.
it needs to be signed by a trusted third party, and the only trusted third party that has ever been (and probably ever will be) supported by mainstream motherboards is microsoft. its been that way since uefi was first introduced. so yes, it would mean that your kernel (or a shim) must be directly (or indirectly) signed by microsoft to satisfy the requirements. that is the quiet part that epic is leaving out.
edit: did more research and it turns out i'm only 90% correct. epic does say they wont accept self-signed kernels, and they do accept some distro kernel sigs *BUT* your motherboard really does only have microsoft keys so none of this matters unless you enroll their keys in your motherboard by hand (which most people are not going to be able to figure out how to do), so it still might as well just be microsoft-signed kernels.
1
u/Navarrog_01R 16h ago
Wouldn't this just be the key for the motherboard itself? They all carry a Microsoft signature, at least the x86 ones, right? In theory, RISC-V boards could work with the distribution's standard keys, provided that EAC v2 were ported to that architecture or so I imagine. Or did I get something wrong? This is a genuine question.
1
u/tyami94 6h ago
the motherboard's firmware forms its root of trust with signing keys provided by msft out-of-the-box. unless you go tinkering with stuff, it will only ever run code that is signed by microsoft (either directly or indirectly). it's not like this for technical reasons, its like this for *political* reasons.
risc-v boards dont do this now, but if windows gets ported to risc-v then microsoft can and probably will mandate that they do in order to be "certified for windows". this is what they did with the early arm devices circa ~2013
1
u/Navarrog_01R 5h ago
If a motherboard can be signed by a trusted Linux distribution, then this shouldn't be an issue. It seems Microsoft already holds a monopoly on motherboard signing, and there’s nothing EAC v2 could do to improve that. Or is there a better way to implement Secure Boot that EAC v2 could leverage? My main issue with the community complaining about EAC v2 is that no one actually offers an alternative. Anyone who plays online knows how complicated things are these days, many games block Linux even though we’re already a minority, and hackers represent an even smaller, more niche group.
→ More replies (0)
11
u/0riginal-Syn 16h ago
Secure Boot on its own is fine. But Microsoft, who didn't even come up with the tech, being the gatekeeper is an issue. It should be independent of a corporation, especially one like Microsoft.
5
u/RAMChYLD 13h ago
This. Somehow Microslop became the gatekeeper for secure boot. It should be an independent third party.
6
u/redit_handoff140 12h ago edited 12h ago
They give a list of well-known keys, many of which aren't Microsoft-based.
While secure boot is originally a M$ thing, it has valid security (even if niche) cases, and is possible to provision without M$ certs.
Bazzite for instance already does this - When you boot the system for the first time you can generate a key pair, generate the certs signed with those keys, and place them for bootloading.
The major difference here is that EG$ is proposing, again as an example, Bazzite do this for the user, and give a copy of the public certificate to EG$ for verifying.
No need to spread misinformation based on decades old stigma.
2
u/sixtyhurtz 4h ago
Microsoft is not the gatekeeper of secure boot. This has literally never been a thing on enthusiast class motherboards. It's really only a problem with cheap pre-built PCs, because they don't always let you easily install your own keys.
It's not MS's fault that cheap pre-builts tend to have shit BIOS that won't let you change the key configuration.
1
u/0riginal-Syn 4h ago
They control the key signing. While you can generate one, it causes issues.
2
u/sixtyhurtz 4h ago
It only causes issues if you boot Windows.
You can delete the MS key, install your own key you generate with OpenSSL, and boot a kernel you have built and signed. I know, I've done it.
1
u/DFrostedWangsAccount 20m ago
Then that kernel won't be accepted by EAC. That's the whole problem with Epic's new system they suggested
1
u/sixtyhurtz 12m ago
I mean, if that's the problem for you then that's fine, but also a bit weird. If you want to join a networked information system with other users on the internet, it's totally valid they want some level of attestation your client hasn't been tampered with.
However, there are lots of people who believe that MS literally controls all secure boot. That it's literally impossible to use your own secure boot keys without having the MS keys enrolled.
That's true for some machines, but if you build your own PC and have a decent motherboard it usually isn't in my experience.
12
u/Rhed0x 22h ago
Pain in the ass to set up with Arch Linux.
→ More replies (16)2
u/PacmanAteMyRAM 18h ago
Took me literally 3 commands, less than 15 seconds.
It won't let you use EACv2 but that's not what you commented.
20
u/total-depravity 22h ago
Why are other people trying to tell me what I can and cannot run on my hardware?
6
u/Erulogos 21h ago
Phones have been getting away with it for a while now, so other corpos want in on that rent seeking (and it is rent seeking, have a few perfectly good older phones that the only issue is lack of updates.)
7
u/total-depravity 21h ago
I see your point, but my pc isn’t a phone. It’s something I built.
To your point, phones are about to get worse and I suspect at some point we won’t have any control or access on them. Which is partly why I’m stunned people would be so excited to lose even more control over their hardware.
→ More replies (3)8
u/steve09089 16h ago edited 6h ago
If you’re talking about the games, they’re just telling you can’t run their games if you run certain things on your hardware.
It’s your choice whether you comply, just like it’s their choice whether they let you play their games. If you don’t want to comply, just don’t buy or get a refund.
2
u/total-depravity 7h ago
I wish it was just related to just one game. It’s related to so much more. It’s firmly rooted in root of trust and who is that source. They want me to trust them but they have no trust in me. It’s already broken at its core.
0
u/Educational_Star_518 12h ago
If you’re talking about the games, they’re just telling you can’t run their games if you run certain things on their hardware.
an amusing freudian slip you got there in that sentence
2
u/steve09089 6h ago
Or that I’m just typing on a phone, but sure, go ahead and interpret something from nothing
7
u/PacmanAteMyRAM 18h ago
They aren't. But to run their software there are rules to ensure some minimum accepted security standards are in check.
3
u/superdreamcast 17h ago edited 17h ago
https://onlineservices.epicgames.com/news/introducing-easy-anti-cheat-linux-v2
These are currently supported signing keys that are currently trusted for Secure Boot, the kernel, and kernel modules. You need systemd for the eBPF anti-cheat service.
- Canonical Ltd. Master Certificate Authority - used by Ubuntu and derived distros like Linux Mint
- Fedora Secure Boot CA - used by Fedora and derived distros like Silverblue
- Universal Blue - used by Bazzite, Bluefin, Aurora, and derived distros
- Debian Secure Boot CA - used by Debian and derived distros
- openSUSE Secure Boot CA - used by openSUSE and derived distros
- SUSE Linux Enterprise Secure Boot CA
- Rocky Linux Secure Boot Root CA
- Microsoft UEFI CA - used to sign non-Microsoft components like the Linux bootloader shim project
- AlmaLinux Secure Boot CA
The anti-cheat eBPF thingy will not run without the stated requirements on Epic's website.
Supposedly Epic is talking with Valve to get this anti-cheat working.
13
u/Confident_Hyena2506 23h ago
It's fine if you use your own keys, but they will want it all signed by microsoft.
7
u/ABotelho23 22h ago
Red Hat usually has root keys on machines these days.
1
u/Confident_Hyena2506 15h ago
Nope - only microsoft keys. They use a microsoft signed bootloader.
1
u/akubukanbuaya 12h ago
only for the 0-stage really small and open source and reproducible shim
grub and the kernel is signed by RH (at least for RHEL)
2
u/Confident_Hyena2506 12h ago
The signed shim is not reproducible, you do not have microsofts private keys.
1
u/akubukanbuaya 11h ago
then how does this case from reproducible project pass the test? you can check the source for real by yourself and it compared the bit-by-bit reproducibility of both unsigned binary and the signed one by microsoft
3
u/Confident_Hyena2506 11h ago
You can compile it sure, but you can't sign it. And the unsigned one will be rejected by secureboot.
So is it REALLY reproducible? Sure by microsoft.
1
u/akubukanbuaya 10h ago
I can compile it and one could also verify that the one signed by microsoft will be the same, bit-by-bit
if this is not enough proof then you can also disregard all criminal cases as the prosecutors and cops can't reproduce a murder and the victim is already dead
2
u/Confident_Hyena2506 10h ago
You are missing the point here - nobody else can make a working signed bootloader - only microsoft can. Only microsoft keys are loaded into EFI boards by default.
Do you really want microsoft to be in control of all linux gaming?
1
u/akubukanbuaya 10h ago
then go complain to EFI board manufacturers, maybe even with this initiative can the Linux Foundation hold a forum on signing keys and they can add more to the list instead of only Microsoft
this just change nothing if you hate it, you cant play those games right now on linux, but opens up for those that wants to play those games on linux
I myself are not playing those games but want this solely for my first point in the future
→ More replies (0)
4
u/anna-the-bunny 6h ago
As others have said, because "Secure Boot" using keys you don't control isn't secure. The entire selling point is that it blocks code that you haven't authorized from running - but if you don't control the keys, you don't control what gets authorized. Not only does that prevent you from running what you want in many cases, but it allows things you don't want (Windows, malware, etc.) to run.
1
2
5
u/MissingGhost 21h ago
I have never enabled secure boot. I have no idea why so many people seem to make a big deal about it.
3
u/annuilein 21h ago
its mostly because secureboot is 100% triopolized by just ubuntu redhat enterprise linux and suse enterprise server linux and anything else has to run self signed keys not to mention that microsoft can just rugpull everyone if they wanted because they own secureboot in its entirety
→ More replies (1)
4
u/calinet6 22h ago
I don’t want to deal with an extra step that does not benefit me one bit. I turn it off.
2
2
1
u/wolfannoy 21h ago
Don't really have an answer for it yet. All we can do is wait and see and find out what happens and what needs to be done.
1
1
u/Specialist-Dog-501 11h ago
AstrOS supports secure boot/TPM, immutability..would be interested to hear if Fortnite works on it, but not a gamer myself and keep testing it.
1
1
u/sidusnare 41m ago
This isn't a problem with SecureBoot, it's a problem with EACv2. EACv2 is requiring specific keys to be the signing keys of the running kernel.
I would be very interested in how they implement this, it could be they have to whitelist all the keys. Since there is no direct connection between the running kernel and the kenrel on disk, they might also insist all kernels in /boot be signed. It's a messy can of worms, and either it gets picky about every little thing or it all falls apart.
So glad I'm not going to play with this mess.
1
u/mindtaker_linux 17h ago
I don't care. But I will not be buying any games that require this to play online. My Dota2 online works fine without this madness. StarCraft 2 works fine online without this madness .
4
6
1
u/JackDostoevsky 21h ago
nothing wrong with SB, wrt the EAC requirements i think the big problem is that no arch-based distro is covered under the current allowed signing keys. i'm hoping they actually get something for that (maybe via Valve? they stated they are in talks with them to get the Steam Deck working)
→ More replies (1)
1
u/NegotiationUnfair626 9h ago
I keep reading that Secure Boot has an issue with Linux, but when I installed Fedora on my PC 5 months ago. I had Secure Boot enabled already because of Windows.. It installed just fine, it didn't prompt me for anything, just installed without a hitch. I guess I don't understand why some people complain about it when I didn't experience any issues at all.
5
u/land_and_air 6h ago
Well fedora is one of like 3 that works because the kernel you downloaded was probably signed by Microsoft. For home users It’s a bit of a security theater at best and at worst it’s just a further method to centralize control of your
Computer away from you and towards centralization1
u/Salander27 11m ago
because the kernel you downloaded was probably signed by Microsoft
Complete BS. Fedora completed an organizational review by Microsoft (or the equivalent program) and as they passed it their signing keys were added to a trusted list. That signing key is used to sign the kernel during the build and the private part of it never leaves the control of Fedora (which is what the organizational review is designed to protect). Microsoft is not involved whatsoever in the signing process (nor will they be in any other distro that completes this process).
1
u/land_and_air 1m ago
I mean that’s just a back door as described, Microsoft decides what trusted software is so thus Microsoft decides what can be run. I hope no one trusts these things with drive encryption. The back door is in the design. The only legitimate usage is self signing software you personally use and blocking all other keys on your hardware or enterprise and this is neither.
1
u/duck-and-quack 3h ago
If you were a Linux user in 2011 you were likely hissing against secure boot because someone told you that it prevents Linux booting .
1
u/sixtyhurtz 4h ago
It's because a very long time ago, there was a thing called the Trusted Computing Initiative. Secure boot was supposed to be part of it. It would have locked down PCs; MS was going to try and use it to stop people dual booting Linux.
None of that actually came to pass though, and pretty much all enthusiast motherboards have always let you install your own keys. So, you can have a secure signed Linux kernel that you build and sign yourself if you like.
Unfortunately, a lot of people who use Linux and fancy themselves as technically informed power users are actually really quite stupid. Most of their knowledge is just half remembered facts they've read on message boards. That's why something that was a huge drama about 25yrs ago is still there as background radiation, and none of them really understand why.
-3
u/MeatPiston 22h ago
Secure boot is security theater.
5
u/ABotelho23 22h ago
It's not though.
1
u/Venylynn 22h ago
I remember when i used to believe this, until secureblue set me on the correct path
-4
u/MeatPiston 22h ago
Trusting a 95 cent lowest bidder chip to hold your keys, running on slapdash uefi firmware published by system vendors that barely work, and you’re running Microsoft’s keys anyway which they pinky swear not to rugpull later.
All for the privilege of your computer not fucking booting when the whole shitty house of cards falls apart.
Security. Fucking. Theater.
1
u/ABotelho23 22h ago
Not all machines only have Microsoft keys. Most new machines also include Red Hat root keys.
Ultimately security is all about layers anyway.
0
u/Venylynn 22h ago
Then why does SecureBlue, aka the only distro actually trying to fix the broken Linux desktop security model, recommend it be enabled?
→ More replies (2)
-3
u/noobjaish 12h ago
People just need something to whine about.
Before everyone kept whining about how gamedevs can simply "flip a switch" to get their game working on Linux which is straight up a lie.
Now they're porting their game over to Linux with anticheat measures so people are whining about that...
Just don't play the game or play with the requirements that they're setting in place because of competitive integrity. People want to have their cake and eat it too and are completely delusional.
People like these are the reason why gamedevs don't give 2 shits about Linux because any form of solution is met with unnecessary lobotimized negativity.
1
u/Spatula0fDoom 11h ago
The switch part is partially true though, because some game developers made that switch to NOT let their games run on Linux.
-6
u/MairusuPawa 22h ago edited 22h ago
Secure Boot is not the point of contention and you missed the entire story, is all. Also why the fuck do you care about a neonazi social website?
2
u/Venylynn 22h ago
Probably because that website, sadly, is still one of the only mainstream places most people use. Bluesky and Mastodon are great but they are barely used. I feel like I'm holding back my promotional ability by only using those.
→ More replies (2)-8
u/Enesce 22h ago
Unless you're an onlyfans girl or a racist, there's no good reason to use Twitter.
3
u/Venylynn 22h ago edited 22h ago
If people actually used the alternatives, it would be easier to stay away and I say that as someone who has been gone since Elon rigged the election for Trump in 2024.
I want to stay away but no one uses the alternatives, which significantly hampers my ability to promote my work as an unsigned artist making experimental-ish metal-leaning music. So i feel like either I stay away and lose out on opportunities to get somewhere with music, or I go back and feel like a piece of shit for falling back in. There's no in between. Millions of people are still using that godforsaken pile of shit site. Meanwhile I scour Bluesky or Mastodon and it's practically dead outside of a few niche circles. I even tried replacing Reddit with Lemmy but Lemmy is barely used as well. The biggest subs are smaller than the small subs here.
0
u/Xarishark 22h ago
>Also why the fuck do you care about a neonazi social website?
Writing that as a comment on reddit is the biggest joke of the year mate😂😂
→ More replies (2)2
u/Venylynn 22h ago
It'd sure be nice if the popular ones weren't the morally questionable ones but whatever ig
193
u/steve09089 23h ago
Can’t use sbctl for this, since they need a central trusted authority, therefore limiting your kernel options to the ones they choose to trust.
Which atm, is SUSE, Fedora, Debian, Ubuntu and Universal Blue.