Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Sun 18 Aug 2019, 12:05
All times are UTC - 4
 Forum index » Off-Topic Area » Security
UEFI + systemd = brick
Post new topic   Reply to topic View previous topic :: View next topic
Page 1 of 1 [6 Posts]  
Author Message
jamesbond

Joined: 26 Feb 2007
Posts: 3357
Location: The Blue Marble

PostPosted: Tue 09 Feb 2016, 00:28    Post subject:  UEFI + systemd = brick
Subject description: systemd
 

Scenario: You are running a Live-CD distro fully in RAM. No savefile, no savefolder, no mounting of any disks.

You run "rm -rf /" (by intent or by accident). All files deleted. System crashes.

No problem right? Just reboot, and everything will be good again - after all, you are running a Live-CD, without any disks mounted, so the "rm" command only delete files in RAM. No data is ever lost. Reboot will re-load that Live-CD and we should be back up in no time. After all, this is what Live-CD is for, right? Right?

Well, if you have a buggy UEFI firmware (which you can't know in advance) and you are running systemd (yes, that evil systemd), you will be in for a VERY BIG SURPRISE when your machine won't boot. The computer won't even go past the boot screen, no boot loader is ever loaded. Your computer has been bricked - as in, *permanently* damaged. And there is no cure short of replacing your motherboard (if this happens on a laptop, make sure you have enough $$$ to get a new one).

Am I joking? Unfortunately, no Evil or Very Mad
http://thenextweb.com/insider/2016/02/01/running-a-single-delete-command-can-permanently-brick-laptops-from-inside-linux/.

The cause - thanks to systemd, that "rm -rf" will delete not only your RAM contents but it will also clear non-volatile config data used by UEFI. Some UEFI firmware can't cope with this "no data" situation and just goes dead.

How could this happen? That's because systemd always mount UEFI config data for read/write, *even* when it is not asked, *even* when it is not needed.

Details:
1. Systemd automatically mounts that UEFI config data as a filesystem, *EVEN* when not asked (the proper place to ask for automatic mounting is in /etc/fstab, but even without any entry in /efc/fstab, systemd will still mount it!)

2. Systemd automatically mounts UEFI data for read-write, well "just-in-case" (see the bug report linked below), even when there is no need to do so. Changing the UEFI data is only needed when you want to change boot configuration and/or boot loaders.
How often do you need to change these two, every minute? Every boot??

Now this in itself is not a story. Buggy software are everywhere and happens all the time. The major gem is how this kind of bug is responded to.

Poettering wrote:
Well, there are tools that actually want to write it. We also expose /dev/sda accessible for root, even though it can be used to hose your system.

The ability to hose a system is certainly reason enought to make sure it's well protected and only writable to root. But beyond that: root can do anything really.

Source: https://github.com/systemd/systemd/issues/2402
In other words: Not my problem (and he immediately closed the bug report, actually). No, Lennart, being root should not automatically enable it to permanently damage my computer by running a regular user command.

Compare this with Linus response when faced with bricked Samsung UEFI laptop scare back in early 2013. His response:
Linus Torvalds wrote:
It has been reported that running this driver on some Samsung laptops with EFI can cause those machines to become bricked as detailed in the following report,

https://bugs.launchpad.net/ubuntu-cdimage/+bug/1040557

There have also been reports of this driver causing Machine Check Exceptions on recent EFI-enabled Samsung laptops, https://bugzilla.kernel.org/show_bug.cgi?id=47121

So disable it if booting from EFI since this driver relies on grovelling around in the BIOS memory map which isn't going to work.

Source: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=e0094244e41c4d0c7ad69920681972fc45d8ce34

EDIT: updated example.

_____________

PS: Almost nobody runs "rm -rf" intentionally. But you may find yourself running "rm -rf / usr/local/apps/old-useless-roxapps". Do you notice the space? Or you may run "export CONFIGDIR=/etc/menus/razor-panel; rm -rf $CONFIG_DIR/*". Notice the extra underscore?
In case you think that these cases sound contrived, the latter *actually happens* ==> https://github.com/ValveSoftware/steam-for-linux/issues/3671.
Thanks to systemd, these kind of typos now not only result in re-installing the OS (or rebooting the Live-CD) but also ends up in buying a new computer. Thanks indeed, all hail SYSTEMD !!

_________________
Fatdog64, Slacko and Puppeee user. Puppy user since 2.13.
Contributed Fatdog64 packages thread.

Last edited by jamesbond on Tue 09 Feb 2016, 11:47; edited 1 time in total
Back to top
View user's profile Send private message 
bark_bark_bark

Joined: 05 Jun 2012
Posts: 1935
Location: Wisconsin USA

PostPosted: Tue 09 Feb 2016, 08:58    Post subject:  

This is why I consider systemD to be basically malware.
_________________
....
Back to top
View user's profile Send private message 
gcmartin

Joined: 14 Oct 2005
Posts: 6730
Location: Earth

PostPosted: Tue 09 Feb 2016, 18:04    Post subject:  

This is timely: I had a colleague few weeks ago asking for help. Seems he had tried to run a Linux distro and had "BRICKED!" his PC. It never comes out of UEFI/BIOS POST, freezing at the vendor splash. I Did not ask if it was a PUP or some other Linux when he contacted me.

The exposes a problem where a distro/package developer could (accidentally/purposefully) clobbers a user's PC. Thus, it is a manner of forcing a user to purchase a new PC.

Thanks for the info. Problem, as it exist, is that there is no way, currently, to protect yourself from this behavior as that is inherent in POST design of today's new PCs. And, I don't expect motherboard-POST vendors to change that as that is probably a manner they use for the BIOS-UEFI loads that they do internally; as well as any field level changes they ship from time to time for their firmware utility's use.

It is a security problem and shows a Linux method to exploit it.

_________________
Get ACTIVE Create Circles; Do those good things which benefit people's needs!
We are all related ... Its time to show that we know this!
3 Different Puppy Search Engines or use DogPile
Back to top
View user's profile Send private message 
cthisbear

Joined: 29 Jan 2006
Posts: 4422
Location: Sydney Australia

PostPosted: Tue 09 Feb 2016, 20:30    Post subject:  

A solution might be...

Disconnect A/C power and take out battery if laptop...
a/c power cord only for a desktop.

Take out ram...disconnect bios battery if laptop...
remove if desktop.

Disconnect hard drives.

Hit Power button to discharge for at least 3o seconds.

Replace power only >> nothing else.

Turn on power...beeps should be heard.

Turn off and re-assemble all.

See if it boots....go into bios and reset to >>Default.

Upon reboot reset bios to settings that suit you.

I am sure that Samsung owners tried a similar approach years ago.

Chris.
Back to top
View user's profile Send private message 
amigo

Joined: 02 Apr 2007
Posts: 2647

PostPosted: Wed 10 Feb 2016, 02:59    Post subject:  

This has nothing to do with systemd -it is the result of /sys being mounted read-write, which is the normal case.
Back to top
View user's profile Send private message 
jamesbond

Joined: 26 Feb 2007
Posts: 3357
Location: The Blue Marble

PostPosted: Wed 10 Feb 2016, 04:54    Post subject:  

Not really. Efivars is a separate filesystem independent from sysfs, just like debugfs. If you only have sysfs mounted, rm -rf won't brick the machine. It's when efivars is mounted then we have problems. Trouble is, systemd mount efivars without being asked to, and it mounts it read/write.

Like I say above, one only needs to mount efivars r/w when one needs to change boot config data e.g change boot loader. This does not happen at every boot so automatic mounting especially r/w mount is indefensible.

Poetter could just say "oops" and immediately fix it - but his ego is too big for that. I haven't read the entire github e ticket but as far as I know nobody has come out on exactly which component of systemd needs efivars mounted r/w at all times.

_________________
Fatdog64, Slacko and Puppeee user. Puppy user since 2.13.
Contributed Fatdog64 packages thread.
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 1 of 1 [6 Posts]  
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Off-Topic Area » Security
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.0740s ][ Queries: 12 (0.0121s) ][ GZIP on ]