this post was submitted on 10 Jan 2025
326 points (95.5% liked)
linuxmemes
21761 readers
1167 users here now
Hint: :q!
Sister communities:
Community rules (click to expand)
1. Follow the site-wide rules
- Instance-wide TOS: https://legal.lemmy.world/tos/
- Lemmy code of conduct: https://join-lemmy.org/docs/code_of_conduct.html
2. Be civil
- Understand the difference between a joke and an insult.
- Do not harrass or attack members of the community for any reason.
- Leave remarks of "peasantry" to the PCMR community. If you dislike an OS/service/application, attack the thing you dislike, not the individuals who use it. Some people may not have a choice.
- Bigotry will not be tolerated.
- These rules are somewhat loosened when the subject is a public figure. Still, do not attack their person or incite harrassment.
3. Post Linux-related content
- Including Unix and BSD.
- Non-Linux content is acceptable as long as it makes a reference to Linux. For example, the poorly made mockery of
sudo
in Windows. - No porn. Even if you watch it on a Linux machine.
4. No recent reposts
- Everybody uses Arch btw, can't quit Vim, <loves/tolerates/hates> systemd, and wants to interject for a moment. You can stop now.
Please report posts and comments that break these rules!
Important: never execute code or follow advice that you don't understand or can't verify, especially here. The word of the day is credibility. This is a meme community -- even the most helpful comments might just be shitposts that can damage your system. Be aware, be smart, don't fork-bomb your computer.
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
The mention of UEFI in this context likely means they are thinking of a deletion recursing through sysfs and by extension deleting all visible UEFI variables which, in some firmware editions and versions, causes it not to be able to get through post or into the setup menu.
I vaguely recall this and the general issue was very bad firmware design, but it was possible to make it impossible to even reinstall a system. If you were industrious in windows you could have done the same thing, so malware under windows could also brick such platforms.
Of course rm has more safeguards on it so you have to pass more flags and really really be asking it to try to screw things up.
Like you said, it was just some early implementations of UEFI. I haven't heard of anything like this happening recently.
Also the kernel makes those variable immutable by default now, except the well known standard ones, so even for buggy UEFI this is mitigated nowadays. Just pointing out it came from a once legitimate space as a consequence of "everything is a file in a monolithic file namespace". Which on the one hand is bad if someone uses rm with all sorts of flags to overrule the "you don't want to do this" protections in the utility. On the other hand what you accidentally managed to do in Linux represented a problem that windows malware could have exploited.
More specifically it has done that for the last 8 years :-D
Nice to know.
So, I would assume the firmware gave write access to a part of permanent memory, critical to starting the system.
I feel like that would be someone like me, thinking of it as a feature and giving the possible values for those variables in the readme. And of course, who reads the readme even though it says "READ ME"?
UEFI defines a structured way to have data shared with OS as read write variables, including the ability to create, modify, and delete variables that UEFI can see.
However, some firmware used this facility to store values and then their code assumed the variables would always be there. The code would then crash when it goes to read a deleted variable and not know what to do. The thing is deleting those variables per spec is a perfectly valid the due the OS to do, but firmware was buggy and the bugs not caught because normally OS would not bother those variables except for a few standard popular ones, like boot order.
I see, in that case, that would not be someone like me :P as I tend to care about specifications.
This is a really useful explanation for someone who doesn't know about the UEFI spec.