Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
On Sat, Feb 06, 2016 at 04:19:07PM +, Rainer Weikusat wrote: > > Each of the mounted filesystems provides a set of methods implementing > the filesystem syscalls for this kind of filesystem and there are no > restriction regarding what these method might do. Eg, one could create a > filesystem where deleting a file named Richard causes an immediate > ACPI poweroff. There's also a Filesystem In Userspace (FUSE) facility > which enables arbitrary applications to implement filesystem syscalls. > > "Invoke unlink/ rmdir methods for all named objects currently visible in > the filesystem namespace" is something very much different from > "fill a disk partition with zeroes" and doing this without knowing what > these unlink/ rmdir methods will end up doing is just recklessly trying > one's luck. The situation is more explicit in the modern filenamespace-based OS's like Plan 9 and Inferno. -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
Steve Litt writes: > Rainer Weikusat wrote: > >> Steve Litt writes: > [clip] >> > With excellent backups, rm -rf / or even dd if=/dev/zero >> > of=/dev/sda1 is correctable with a few hours of work, on the >> > premises, with only resources on the premises. >> >> A somewhat seriously wrong conception about the relation between / >> (the root of the filesystem name tree) and /dev/sda1 (some partition >> of a mass storage device) seems to exist here. The reality is "there >> is none" unless the system happens to be configured such >> that /dev/sda1 is mounted as / > > Come on, Rainer, it's obvious your last sentence is assumed in my > statement. My sentence continued with , | and nothing else has been integrated into the filesystem | namespace. ` which obviously wasn't the situation you were writing about as 'deleteing EFI variables' at least requires the efivarfs filesystem to be mounted. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
On Sat, 06 Feb 2016 16:19:07 + Rainer Weikusat wrote: > Steve Litt writes: [clip] > > With excellent backups, rm -rf / or even dd if=/dev/zero > > of=/dev/sda1 is correctable with a few hours of work, on the > > premises, with only resources on the premises. > > A somewhat seriously wrong conception about the relation between / > (the root of the filesystem name tree) and /dev/sda1 (some partition > of a mass storage device) seems to exist here. The reality is "there > is none" unless the system happens to be configured such > that /dev/sda1 is mounted as / Come on, Rainer, it's obvious your last sentence is assumed in my statement. What, did I have to completely specify it just to make the obvious point that wiping the root dir's device is correctable from a good backup? SteveT Steve Litt February 2016 featured book: The Key to Everyday Excellence http://www.troubleshooters.com/key ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
Le 06/02/2016 17:19, Rainer Weikusat a écrit : Steve Litt writes: >On Fri, 5 Feb 2016 18:33:44 +0100 Didier Kryn wrote: > >> People have always expected rm -rf / to destroy the OS. They >>also know that, from the keyboard, with root priviledge, they can >>destroy the partition table of the disk. All this is repairable by >>the admin her/himself. >> >> The ability to brick the motherboard is brand new. > >Not only brand new, but an entirely new level of consequence. > >With excellent backups, rm -rf / or even dd if=/dev/zero of=/dev/sda1 is >correctable with a few hours of work, on the premises, with only >resources on the premises. A somewhat seriously wrong conception about the relation between / (the root of the filesystem name tree) and /dev/sda1 (some partition of a mass storage device) seems to exist here. Sure Rainer, admins with a little of experience know that. This was just a partial enumeration of simple actions able to destroy an installed OS. You are right to insist on the BIG difference between these two actions and the fact that rm -rf is much more destructive than reformatting /. However, the main danger of rm -rf, up to now, was typically its potential to wipe out /home. None of the pseudofilesystem represented a danger. Experienced people running this command would just unmount any filesystem they would like to preserve and would never have thought of this new, well hidden, danger. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
Simon Hobson writes: > Rainer Weikusat wrote: >> But "the hardware" didn't "break". Certain vendor-supplied software >> reportedly ceases to function if certain EFI variables are deleted. > > That is the sort of linguistic gymnastics that vendors use to get out > of accepting responsibility for stuff. I think most people would > equate with "it used to work", "X happened", "it now doesn't work" as > being "X broke it". It no longer works, it's broken. Using linguistic > gymnastics to try and call it something else doesn't change the > fundamental fact that "it no longer works, therefore it's broken". That's (AFAIK) a factually accurate description and not 'linguistic gymnastics' and the final effect of this, namely, perfectly working hardware is rendered unusable because of unsafe software implementation practices, is IMHO rather more damning than "the hardware's broken" as physical things are affected by wear and tear while software isn't. It also avoids a Daily Mail style "Using Linux can brick your hardware!" statement. That's not really wrong but nevertheless rather removed from the actual situation. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
Steve Litt writes: > On Fri, 5 Feb 2016 18:33:44 +0100 Didier Kryn wrote: > >> People have always expected rm -rf / to destroy the OS. They >> also know that, from the keyboard, with root priviledge, they can >> destroy the partition table of the disk. All this is repairable by >> the admin her/himself. >> >> The ability to brick the motherboard is brand new. > > Not only brand new, but an entirely new level of consequence. > > With excellent backups, rm -rf / or even dd if=/dev/zero of=/dev/sda1 is > correctable with a few hours of work, on the premises, with only > resources on the premises. A somewhat seriously wrong conception about the relation between / (the root of the filesystem name tree) and /dev/sda1 (some partition of a mass storage device) seems to exist here. The reality is "there is none" unless the system happens to be configured such that /dev/sda1 is mounted as / and nothing else has been integrated into the filesystem namespace. But usually, this won't be the case and a number of devices/ partitions and virtual filesystems providing various features will collectively provide 'named objects' which can be manipulated using the filesystem API. The current list can be displayed with cat /proc/mounts , | For historical reasons, the mount command also maintains a list of | mounted filesystems in the file /etc/mtab which it displays when | executed without arguments. But the current /etc/mtab doesn't | necessarily reflect reality, eg, because / is mounted r/o or because the | current / came into being via chroot. ` Each of the mounted filesystems provides a set of methods implementing the filesystem syscalls for this kind of filesystem and there are no restriction regarding what these method might do. Eg, one could create a filesystem where deleting a file named Richard causes an immediate ACPI poweroff. There's also a Filesystem In Userspace (FUSE) facility which enables arbitrary applications to implement filesystem syscalls. "Invoke unlink/ rmdir methods for all named objects currently visible in the filesystem namespace" is something very much different from "fill a disk partition with zeroes" and doing this without knowing what these unlink/ rmdir methods will end up doing is just recklessly trying one's luck. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
Is it true that /sys/firmware/efi is also mounted rw under sysvinit? Apologies if I missed the answer to this question in this long thread. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
Le 06/02/2016 13:32, Arnt Karlsen a écrit : On Fri, 5 Feb 2016 22:46:59 -0500, Hendrik wrote in message <20160206034659.ga23...@topoi.pooq.com>: On Fri, Feb 05, 2016 at 09:38:10PM -0500, fsmithred wrote: On 02/05/2016 08:48 PM, Joel Roth wrote: Didier Kryn wrote: The ability to brick the motherboard is brand new. Therefore admins should be seriously protected and warned against this eventuality, at least until it percolates into the general culture. IIUC, this means malware will now be able to not only erase, but to render its targets unbootable. Also creating a new hardware recovery business. It seems somewhat bleak. Am I overreacting? Go with the flow, dude. It's worth the risk of malware for the benefit of having your vendor push firmware updates whenever they want. (Did I get that right?) Actually, I think you're underreacting. I would edit your statement to say, "...render its targets unbootable or worse." Malware authors and others who might have bad intentions for your hardware generally want it to keep working. Perhaps not in warfare. ..against whom? Apple against Linux Systemd against Freedom of choice Crapware against good software Pick your preferred :D Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
On 02/05/2016 09:38 PM, fsmithred wrote: > On 02/05/2016 08:48 PM, Joel Roth wrote: >> Didier Kryn wrote: >>> The ability to brick the motherboard is brand new. Therefore admins >>> should be seriously protected and warned against this eventuality, at least >>> until it percolates into the general culture. >> IIUC, this means malware will now be able to not only >> erase, but to render its targets unbootable. >> Also creating a new hardware recovery business. >> It seems somewhat bleak. Am I overreacting? >> >> > Go with the flow, dude. It's worth the risk of malware for the benefit of > having your vendor push firmware updates whenever they want. (Did I get > that right?) > > Actually, I think you're underreacting. I would edit your statement to > say, "...render its targets unbootable or worse." Malware authors and > others who might have bad intentions for your hardware generally want it > to keep working. > > Yes I understand the EFI is a dandy place to conceal stuff if you want it to survive to next boot and not be disadvantaged by _most_ hard drive cleaning games. Leaving it RW from the OS is just extra convenient for installation, how nice. Probably gets the NSA stamp of approval. Clarke ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
On Fri, 5 Feb 2016 22:46:59 -0500, Hendrik wrote in message <20160206034659.ga23...@topoi.pooq.com>: > On Fri, Feb 05, 2016 at 09:38:10PM -0500, fsmithred wrote: > > On 02/05/2016 08:48 PM, Joel Roth wrote: > > > Didier Kryn wrote: > > >> > > >> The ability to brick the motherboard is brand new. Therefore > > >> admins should be seriously protected and warned against this > > >> eventuality, at least until it percolates into the general > > >> culture. > > > > > > IIUC, this means malware will now be able to not only > > > erase, but to render its targets unbootable. > > > Also creating a new hardware recovery business. > > > It seems somewhat bleak. Am I overreacting? > > > > > > > > > > Go with the flow, dude. It's worth the risk of malware for the > > benefit of having your vendor push firmware updates whenever they > > want. (Did I get that right?) > > > > Actually, I think you're underreacting. I would edit your statement > > to say, "...render its targets unbootable or worse." Malware > > authors and others who might have bad intentions for your hardware > > generally want it to keep working. > > Perhaps not in warfare. ..against whom? -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
On Fri, Feb 05, 2016 at 09:38:10PM -0500, fsmithred wrote: > On 02/05/2016 08:48 PM, Joel Roth wrote: > > Didier Kryn wrote: > >> > >> The ability to brick the motherboard is brand new. Therefore admins > >> should be seriously protected and warned against this eventuality, at least > >> until it percolates into the general culture. > > > > IIUC, this means malware will now be able to not only > > erase, but to render its targets unbootable. > > Also creating a new hardware recovery business. > > It seems somewhat bleak. Am I overreacting? > > > > > > Go with the flow, dude. It's worth the risk of malware for the benefit of > having your vendor push firmware updates whenever they want. (Did I get > that right?) > > Actually, I think you're underreacting. I would edit your statement to > say, "...render its targets unbootable or worse." Malware authors and > others who might have bad intentions for your hardware generally want it > to keep working. Perhaps not in warfare. -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
On 02/05/2016 08:48 PM, Joel Roth wrote: > Didier Kryn wrote: >> >> The ability to brick the motherboard is brand new. Therefore admins >> should be seriously protected and warned against this eventuality, at least >> until it percolates into the general culture. > > IIUC, this means malware will now be able to not only > erase, but to render its targets unbootable. > Also creating a new hardware recovery business. > It seems somewhat bleak. Am I overreacting? > > Go with the flow, dude. It's worth the risk of malware for the benefit of having your vendor push firmware updates whenever they want. (Did I get that right?) Actually, I think you're underreacting. I would edit your statement to say, "...render its targets unbootable or worse." Malware authors and others who might have bad intentions for your hardware generally want it to keep working. fsr ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
Didier Kryn wrote: > > The ability to brick the motherboard is brand new. Therefore admins > should be seriously protected and warned against this eventuality, at least > until it percolates into the general culture. IIUC, this means malware will now be able to not only erase, but to render its targets unbootable. Also creating a new hardware recovery business. It seems somewhat bleak. Am I overreacting? -- Joel Roth ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
On 02/05/2016 01:20 PM, Steve Litt wrote: > On Fri, 5 Feb 2016 18:33:44 +0100 > Didier Kryn wrote: > >> People have always expected rm -rf / to destroy the OS. They >> also know that, from the keyboard, with root priviledge, they can >> destroy the partition table of the disk. All this is repairable by >> the admin her/himself. >> >> The ability to brick the motherboard is brand new. > > Not only brand new, but an entirely new level of consequence. > > > With a well backed up machine, there is absolutely no comparison > between loss of the system disk formatting and bricking of the mobo. > >> Therefore >> admins should be seriously protected and warned against this >> eventuality, at least until it percolates into the general culture. > > Yes. > > > SteveT > Along those lines, we should probably be taking notes on what motherboards are susceptible to this. Is there some way to test a motherboard to see if it's brickable this way without actually bricking it? Did anyone get the model number of the MSI notebook in the original thread at the Arch linux forum before that thread disappeared? fsr ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
On Fri, 5 Feb 2016 18:33:44 +0100 Didier Kryn wrote: > People have always expected rm -rf / to destroy the OS. They > also know that, from the keyboard, with root priviledge, they can > destroy the partition table of the disk. All this is repairable by > the admin her/himself. > > The ability to brick the motherboard is brand new. Not only brand new, but an entirely new level of consequence. With excellent backups, rm -rf / or even dd if=/dev/zero of=/dev/sda1 is correctable with a few hours of work, on the premises, with only resources on the premises. Bricking the mobo means buying a new mobo, and in all likelihood a whole computer. Unless the mobo is still being sold, this means a brand new hardware cost/benefit analysis. If you don't live near a good computer store, it could mean mail order, with the several days' shipping and the RMA nonsense, while your business languishes. I could see an rm -rf causing a business to be down for a couple weeks, complete with angry threats and counterthreats between business and computer vendor. Anybody who's ever had to buy a computer to fix a current outage, instead of as a planned process, knows you're going to get an inferior computer for an inflated price, and incur the kind of pressure that makes mistakes more probable. It's not a whole lot different than having to buy a car tonight because your old car blew up this afternoon and you'll get fired if you don't drive to work tomorrow. With a well backed up machine, there is absolutely no comparison between loss of the system disk formatting and bricking of the mobo. > Therefore > admins should be seriously protected and warned against this > eventuality, at least until it percolates into the general culture. Yes. SteveT Steve Litt February 2016 featured book: The Key to Everyday Excellence http://www.troubleshooters.com/key ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
On Fri, 5 Feb 2016 11:39:15 + Simon Hobson wrote: > KatolaZ wrote: > > > I don't get why any of those occasional "sysadmin-wannabe" users you > > have described above would ever need to mess around with their UEFI > > by hand. > > They don't. But certain tasks they run apparently can do - did > someone mention Grub updating it ? New kernels and corresponding initramf files are created every couple weeks, and there's a need to seemlessly get the system to boot the latest. I imagine there are solutions for this that don't involve mods to EFI vars. One I imagine is that grub is permanently set to kernel kernel.symlink with initramfs initramfs.symlink, so that changing kernels is nothing but changing symlinks. I think hard links would work too. If that doesn't work in such a low level of boot (and I don't know what it wouldn't), just name the latest kernel kernel.latest. As far as poettering's necessary-to-life-itself thing of telling the EFI what to boot next, I'm pretty sure this could be done a little farther from the EFI. SteveT Steve Litt February 2016 featured book: The Key to Everyday Excellence http://www.troubleshooters.com/key ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
Le 05/02/2016 16:33, Rainer Weikusat a écrit : "Rainer H. Rauschenberg" writes: On Thu, 4 Feb 2016, Simon Hobson wrote: [...] Besides that I don't think mounting EFI-vars r/w is a good idea as a system default and I don't think the user not having read all the relevant documentation (spread out over various places) is to blame when system behaviour *changes* in such a drastic way (bricking hardware by deleting "files"). 'Virtual filesystems' have existed since at least 1985 (SunOS 2.0) and Linux has supported various types of virtual filesystems for a really long time. Consequently, there's no "system behaviour which changed in a drastic way" here. What precisely happens when some program executes an unlink system call depends on the filesystem implementation. Even leaving this aside, there's a very simple rule-of-thumb here, namely, "if you don't know what it's good for then *don't* delete it" (unless you're making an experiment and you're willing to accept that the outcome was caused by you and not by the universe being nasty to you). People have always expected rm -rf / to destroy the OS. They also know that, from the keyboard, with root priviledge, they can destroy the partition table of the disk. All this is repairable by the admin her/himself. The ability to brick the motherboard is brand new. Therefore admins should be seriously protected and warned against this eventuality, at least until it percolates into the general culture. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
Rainer Weikusat wrote: > But "the hardware" didn't "break". Certain vendor-supplied software > reportedly ceases to function if certain EFI variables are deleted. That is the sort of linguistic gymnastics that vendors use to get out of accepting responsibility for stuff. I think most people would equate with "it used to work", "X happened", "it now doesn't work" as being "X broke it". It no longer works, it's broken. Using linguistic gymnastics to try and call it something else doesn't change the fundamental fact that "it no longer works, therefore it's broken". It is true that the "true hardware" didn't "break", but in this context, "the hardware" is the sum of the physical hardware, the firmware it runs, and the configuration files for that firmware. I see your argument that it's "the user broke the firmware" - but the end result is still that "the hardware no longer works" - ie it's broken. I also agree 100% that the firmware writers have royally f***ed up on this. Deleting files off a disk can be recovered from (at least in terms of, you can re-install an OS on it) and you still have working hardware. Having a "software" system where deleting a file makes it unrecoverable is inexcusable. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
On Fri, Feb 05, 2016 at 04:14:49PM +, Rainer Weikusat wrote: [cut] > > It's not really that simple: This really an interesting multi-level > fuck-up. > > - the systemd people shouldn't just mount the efivarfs r/w > because that's convenient for them and tell people to get lost > if they think otherwise > > - someone who runs rm -rf on a group of mounted filesystems > should understand that whatever was affected by that didn't > chose to unlink itself > > - the people who implemented the firmware shouldn't have > implemented that such that it ceases to work if userspace > software performs perfectly legitimate operations such as > deleting unprotected variables > > [- the issue shouldn't be generalized until the answer becomes > 42 ] > I agree that it's surely a mixture of different fuck-ups, but there is no reason to make it easier for people to accidentally brick their laptops. To the best of my knowledge, you can't brick your laptop by unlinking any file in any other virtual filesystem. The most you can get is a kernel panic, in a few very specific situations. You reboot and you are fine. With UEFI is apparently a completely different story, so users should have been told, IMHO. HND KatolaZ -- [ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ] [ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ] [ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ] [ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ] ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
KatolaZ writes: > On Thu, Feb 04, 2016 at 10:02:51PM +, Simon Hobson wrote: >> Arnt Karlsen wrote: >> >> > ..me, I do not see any point in keeping it mounted at all. >> > Whenever such a need arises, it should be mounted read-only. >> > If a need to write to /sys/firmware/efi/efivars should happen, >> > the machine should first be taken off-line, backed-up etc out >> > of production and into a maintenance mode, where mounting >> > /sys/firmware/efi/efivars read-write, _may_ be warranted. >> >> >> Yes, in an ideal world where everyone is a "full time admin". But in >> the real world, more systems are used by "average users" who just >> expect "stuff to work". So IMO, you either build stuff that works (or >> at least is up-front about what's wrong), or you leave these people >> stuck with "stuff that's broken" and regardless of how right you are, >> the pi**ed off user will be moaning about how "rubbish and >> complicated this Linux is - best go back to Windows". >> > > I don't get why any of those occasional "sysadmin-wannabe" users you > have described above would ever need to mess around with their UEFI by > hand. If you need to do that, you should first *know* what you are > doing. It's not really that simple: This really an interesting multi-level fuck-up. - the systemd people shouldn't just mount the efivarfs r/w because that's convenient for them and tell people to get lost if they think otherwise - someone who runs rm -rf on a group of mounted filesystems should understand that whatever was affected by that didn't chose to unlink itself - the people who implemented the firmware shouldn't have implemented that such that it ceases to work if userspace software performs perfectly legitimate operations such as deleting unprotected variables [- the issue shouldn't be generalized until the answer becomes 42 ] ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
Edward Bartolo writes: > The argument of those who support protecting the hardware against a > probable breakage are logically sound: I support them. But "the hardware" didn't "break". Certain vendor-supplied software reportedly ceases to function if certain EFI variables are deleted. And the vendor apparently couldn't be bothered with making these variables undeletable if they were intended to be undeletable. In an ideal world, this should be covered by warranty as that's obviously a technical defect, however, people working for said vendors will doubtlessly also prefer to blame someone else instead. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
On 06/02/16 00:18, Hendrik Boom wrote: On Fri, Feb 05, 2016 at 11:39:15AM +, Simon Hobson wrote: Of course, unless you physically remove support for the virtual filesystem, then there's nothing to stop any program with enough privileges to mount the filesystem when it wants. And that's the proble with the root model of administrative software. You either have all the privileges to do anything, or none. There's no mechanism to be granted jusst the provileges actually needed. hence the use of groups for specific purposes, with group ownership of certain things ... but the core idea that the person who buys the gear is not ultimately locked out of anything means that they cannot be protected from themselves if they really insist ... that is as it should be. But they should be warned, and not have nasty traps placed in front of them ... especially very nasty traps. This shifts significantly if the owner of the gear wants to leave it physically in the hands of a user they do not trust, then locking it down is reasonable. Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
"Rainer H. Rauschenberg" writes: > On Thu, 4 Feb 2016, Simon Hobson wrote: [...] > Besides that I don't think mounting EFI-vars r/w is a good idea as a > system default and I don't think the user not having read all the > relevant documentation (spread out over various places) > is to blame when system behaviour *changes* in such a drastic way > (bricking hardware by deleting "files"). 'Virtual filesystems' have existed since at least 1985 (SunOS 2.0) and Linux has supported various types of virtual filesystems for a really long time. Consequently, there's no "system behaviour which changed in a drastic way" here. What precisely happens when some program executes an unlink system call depends on the filesystem implementation. Even leaving this aside, there's a very simple rule-of-thumb here, namely, "if you don't know what it's good for then *don't* delete it" (unless you're making an experiment and you're willing to accept that the outcome was caused by you and not by the universe being nasty to you). Random story which fits in nicely here: Once upon a time in the past, I witnessed a Real Man[tm] being conquered by a computerized spin dryer. Not happy with reading or even following the operating instructions, he chose to try to beat it into submission by hammering his fists onto the control panel instead. This caused the machine to display "Error". Apparently infuriated by that, he hit it more violently but the display just stubbornly showed this single word. After a while, the man would tire of the exertion and stop beating the appliance. The display then changed back to signal that the machine was ready for being used. He would then randomly press a few buttons but without the intended effect. Then go back to hitting it. And the display went back "Error". I witnessed a few cycles before before leaving laundromat. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
On Fri, Feb 05, 2016 at 11:39:15AM +, Simon Hobson wrote: > > Of course, unless you physically remove support for the virtual > filesystem, then there's nothing to stop any program with enough > privileges to mount the filesystem when it wants. And that's the proble with the root model of administrative software. You either have all the privileges to do anything, or none. There's no mechanism to be granted jusst the provileges actually needed. -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
KatolaZ wrote: > I don't get why any of those occasional "sysadmin-wannabe" users you > have described above would ever need to mess around with their UEFI by > hand. They don't. But certain tasks they run apparently can do - did someone mention Grub updating it ? So one scenario (which I think is the most likely) goes like this : User instructs system to install updates (whether that's via cli "apt-get ..." or by clicking in a GUI). One (or more) of those updates triggers a Grub update. Grub runs update process, and for whatever reason wants to update UEFI settings. To cater for this, certain camps have set the default to "mount the virtual filesystem r/w all the time" - which has the dangers discussed. Some are suggesting that the user should have to manually mount it for these occasions. My feeling is that this puts an unnecessary technical burden on the less knowledgeable, some of whom will take the attitude that "it's broken" when updates don't install properly. My suggestion is to (re)mount r/w when this occurs - by default asking the user permission first - and either unmount or remount r/o afterwards. A config option could be provided (in a config file) so the utilities needing to do this could assume permission and do it transparently - *IF* the user/admin sets that option. Thos that don't want the filesystem mounted, ever, without them manually doing it can easily adjust fstab and settings to allow for that. IMO this caters for for those who want it to "just happen", for those that want to have to give permission each time, and those who want full manual control. Of course, unless you physically remove support for the virtual filesystem, then there's nothing to stop any program with enough privileges to mount the filesystem when it wants. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
On Thu, Feb 04, 2016 at 10:02:51PM +, Simon Hobson wrote: > Arnt Karlsen wrote: > > > ..me, I do not see any point in keeping it mounted at all. > > Whenever such a need arises, it should be mounted read-only. > > If a need to write to /sys/firmware/efi/efivars should happen, > > the machine should first be taken off-line, backed-up etc out > > of production and into a maintenance mode, where mounting > > /sys/firmware/efi/efivars read-write, _may_ be warranted. > > > Yes, in an ideal world where everyone is a "full time admin". But in the real > world, more systems are used by "average users" who just expect "stuff to > work". So IMO, you either build stuff that works (or at least is up-front > about what's wrong), or you leave these people stuck with "stuff that's > broken" and regardless of how right you are, the pi**ed off user will be > moaning about how "rubbish and complicated this Linux is - best go back to > Windows". > I don't get why any of those occasional "sysadmin-wannabe" users you have described above would ever need to mess around with their UEFI by hand. If you need to do that, you should first *know* what you are doing. My2Cents KatolaZ -- [ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ] [ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ] [ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ] [ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ] ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
Rainer H. Rauschenberg wrote: > I think this is the road that led to systemd -- if you think Linux needs > to be "as easy as Windows" you tend to take away all the aspects that made > it superior (in my view). I think I didn't really express my position very well. I'm not advocating "taking all the good stuff away" - after all, I'm ready enough at work (a mostly MS shop) to describe the command prompt as "like Unix with all the useful stuff removed" :-) But if you ignore the needs of the majority, then you more or less consign the project to being "one of those obscure distros that few use". I'm not suggesting the Windows/SysemD route either - just lose the "guru or find somewhere else" attitude to users that some people seem to hold. And note that I proposed something that, IMO, treads the fine line between supporting those who want control, and those who are happy to let the system do it. One setting that defaults to control, but can be easily changed for those that are happy with the system dealing with it. And of course, for those that don't want it mounted at all, they can always remove it from fstab (or mark it as not automatically mounted). I believe that's the 3 use cases that will suit 99+% of users of all abilities. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
On 05/02/16 15:30, Edward Bartolo wrote: Hi, The argument of those who support protecting the hardware against a probable breakage are logically sound: I support them. I see it simpler than that. I've always believed that best practice was if you don't need it mounted rw, then don't. For example all my machines (deskop, laptop & servers) always have /boot as a separate small partition. It's always kept mounted ro unless I need to update the kernel or bootloader. I have a couple of EFI machines (Macs) and I sure as heck don't keep any of the EFI firmware directories even mounted, let alone mounted rw. I see it as another "Well it makes our life easier, we don't see a problem with it and if you nuke your system it's really not our fault even though we did it behind your back without warning". Which is why I'm here after 20 years of exclusive Debian use. I tried systemd during the Jessie freeze. It broke during the upgrade and I got lost trying to figure out how to fix it. I can fix a broken SysV system in my sleep, and I'm old enough not to want to learn new stuff just because someone thinks it's a good idea. Brad. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
Hi, The argument of those who support protecting the hardware against a probable breakage are logically sound: I support them. Let us look at it differently and let us consider the switching power supply that supplies stable voltages to the various circuits of a computer. Would anyone agree that design engineers do not prevent any possibility in the negative feedback loops and pulsewidth modulation circuitry, to safeguard against voltage outputs that are harmful to the hardware? Then, why on Flat Earth should anyone accept that software should NOT be prevented from damaging hardware? Now, I am waiting for the usual counter pseudo-argument, namely, that this is another scenario that has nothing to do with the subject being discussed. Oh, I have wasted enough of my time. Edward On 05/02/2016, Rainer H. Rauschenberg wrote: > On Thu, 4 Feb 2016, Simon Hobson wrote: > >> Yes, in an ideal world where everyone is a "full time admin". But in the >> real world, more systems are used by "average users" who just expect >> "stuff to work". So IMO, you either build stuff that works (or at least >> is up-front about what's wrong), or you leave these people stuck with >> "stuff that's broken" and regardless of how right you are, the pi**ed >> off user will be moaning about how "rubbish and complicated this Linux >> is - best go back to Windows". > > I think this is the road that led to systemd -- if you think Linux needs > to be "as easy as Windows" you tend to take away all the aspects that made > it superior (in my view). > > Most of the people in the Linux community who shout so loud focus on this > kind of target, so devuan better should focus on the people who want less > automagic and more control. > > Besides that I don't think mounting EFI-vars r/w is a good idea as a > system default and I don't think the user not having read all the > relevant documentation (spread out over various places) is to blame when > system behaviour *changes* in such a drastic way (bricking hardware by > deleting "files"). > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng > ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
On Thu, 4 Feb 2016, Simon Hobson wrote: > Yes, in an ideal world where everyone is a "full time admin". But in the > real world, more systems are used by "average users" who just expect > "stuff to work". So IMO, you either build stuff that works (or at least > is up-front about what's wrong), or you leave these people stuck with > "stuff that's broken" and regardless of how right you are, the pi**ed > off user will be moaning about how "rubbish and complicated this Linux > is - best go back to Windows". I think this is the road that led to systemd -- if you think Linux needs to be "as easy as Windows" you tend to take away all the aspects that made it superior (in my view). Most of the people in the Linux community who shout so loud focus on this kind of target, so devuan better should focus on the people who want less automagic and more control. Besides that I don't think mounting EFI-vars r/w is a good idea as a system default and I don't think the user not having read all the relevant documentation (spread out over various places) is to blame when system behaviour *changes* in such a drastic way (bricking hardware by deleting "files"). ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
Arnt Karlsen wrote: > ..me, I do not see any point in keeping it mounted at all. > Whenever such a need arises, it should be mounted read-only. > If a need to write to /sys/firmware/efi/efivars should happen, > the machine should first be taken off-line, backed-up etc out > of production and into a maintenance mode, where mounting > /sys/firmware/efi/efivars read-write, _may_ be warranted. Yes, in an ideal world where everyone is a "full time admin". But in the real world, more systems are used by "average users" who just expect "stuff to work". So IMO, you either build stuff that works (or at least is up-front about what's wrong), or you leave these people stuck with "stuff that's broken" and regardless of how right you are, the pi**ed off user will be moaning about how "rubbish and complicated this Linux is - best go back to Windows". Rainer Weikusat wrote: > 'A distribution' would usually provide some default settings for > mounting virtual filesystems but I don't really care what these are. If > I don't consider such a filesystem particularly useful, I wouldn't be > running a kernel supporting it at all and if I did, I'd change the > defaults to whatever I consider sensible. That's fair enough, you are clearly in a position to do that. But as per above, the vast majority of users are not. > I'd be seriously annoyed by some software which would silently remount > stuff I've chose to mount r/o r/w (and back in the hope it'll never be > caught red-handed) instead of complaining that blablala can't be done > because lalala can't be written to. Which is why I suggested a scheme that stops, prompts the user, and if the user says yes then goes ahead and does it - with an option that the user can set (file in /etc/default with suitable comments ?) that allows those who don't want the prompt every time to tell the system "just do it". Seems to me, that would provide a working default that a) protects (as far as possible) the UEFI fs, b) puts the user in control of access to it (assuming random sh*t doesn't just go ahead and ignore the users settings). ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
Dave Turner writes: > Simon old chap, we are ALL geeks here! And thus by definition on the > edge of just about all normal spectra... > I think Rainer is probably diametrically opposite to me on the weirdo > spectrum! Like all normal people, I'm convinced I'm normal and everybody else is weird. https://www.youtube.com/watch?v=U1KGuUKh5Zg ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
> > ..me, I do not see any point in keeping it mounted at all. > Whenever such a need arises, it should be mounted read-only. > If a need to write to /sys/firmware/efi/efivars should happen, > the machine should first be taken off-line, backed-up etc out > of production and into a maintenance mode, where mounting > /sys/firmware/efi/efivars read-write, _may_ be warranted. > > +1 -- -- aldemir ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
Steve Litt writes: [...] > Is there anyone on this list who would object to *Devuan* mounting > /sys/firmware/efi/efivars read-only? 'A distribution' would usually provide some default settings for mounting virtual filesystems but I don't really care what these are. If I don't consider such a filesystem particularly useful, I wouldn't be running a kernel supporting it at all and if I did, I'd change the defaults to whatever I consider sensible. I'd be seriously annoyed by some software which would silently remount stuff I've chose to mount r/o r/w (and back in the hope it'll never be caught red-handed) instead of complaining that blablala can't be done because lalala can't be written to. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
Simon old chap, we are ALL geeks here! And thus by definition on the edge of just about all normal spectra... I think Rainer is probably diametrically opposite to me on the weirdo spectrum! DaveT On 04/02/16 13:27, Simon Hobson wrote: Didier Kryn wrote: for the real "general case", someone who blindly trusts the advice of strangers despite he doesn't understand it will end up getting himself in trouble sooner or later and probably rather sooner than later. Eg nearly any client of a physician, a lawyer... :-) It's hard to work out whether Rainer is trolling or just really out of touch with the real world. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
On Thu, 4 Feb 2016 13:33:33 -0500, Steve wrote in message <2016020413.720b2...@mydesk.domain.cxm>: > On Thu, 04 Feb 2016 17:42:35 + > Rainer Weikusat wrote: > > > Simon Hobson writes: > > > Rainer Weikusat wrote: > > > > > >> "Whoever disagrees with me MUST either have a hidden, maliscious > > >> agenda or be out of his mind" is a pretty standard way to > > >> (attempt to) handle a situation where someone ran out of > > >> arguments but doesn't feel like admitting that. > > > > > > Not at all. I have a perfectly sound argument. You are stubbornly > > > trolling that users deserve to have their hardware bricked. > > > > I never wrote "users deserve ot have their hardware bricked". That's > > another generalization you invented. Apart from that, none of your > > snide remarks about me is even remotely related to the topic under > > discussion. > > This discussion is getting pretty theoretical and philosophical. So > let me ask this question: Is there anyone on this list who would > object to *Devuan* mounting /sys/firmware/efi/efivars read-only? ..me, I do not see any point in keeping it mounted at all. Whenever such a need arises, it should be mounted read-only. If a need to write to /sys/firmware/efi/efivars should happen, the machine should first be taken off-line, backed-up etc out of production and into a maintenance mode, where mounting /sys/firmware/efi/efivars read-write, _may_ be warranted. -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
Steve Litt writes: > On Thu, 4 Feb 2016 09:36:05 + > Simon Hobson wrote: > >> Trash the OS - fair game (maybe). Brick the hardware, that's another >> kettle of fish. > > Another (and consistent) view is that we had a deal. From 1969 til > 2013, we had a deal that if you backed up every day and then used a bad > rf command, restoration to the beginning of the day would be a couple > hours of work, and that's it. Support for the 'EFI variables' filesystem was added to Linux in 2012, https://lwn.net/Articles/518690/ Your argument would still seem to be with 'Linux'. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
On Thu, 04 Feb 2016 17:42:35 + Rainer Weikusat wrote: > Simon Hobson writes: > > Rainer Weikusat wrote: > > > >> "Whoever disagrees with me MUST either have a hidden, maliscious > >> agenda or be out of his mind" is a pretty standard way to (attempt > >> to) handle a situation where someone ran out of arguments but > >> doesn't feel like admitting that. > > > > Not at all. I have a perfectly sound argument. You are stubbornly > > trolling that users deserve to have their hardware bricked. > > I never wrote "users deserve ot have their hardware bricked". That's > another generalization you invented. Apart from that, none of your > snide remarks about me is even remotely related to the topic under > discussion. This discussion is getting pretty theoretical and philosophical. So let me ask this question: Is there anyone on this list who would object to *Devuan* mounting /sys/firmware/efi/efivars read-only? SteveT Steve Litt February 2016 featured book: The Key to Everyday Excellence http://www.troubleshooters.com/key ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
2016-02-04 18:53 GMT+01:00 Rainer Weikusat : > Wim writes: > > [...] > > > I'd like to see Devuan do better. Better than Debian, fi. Windows doesn't > > seem to have this problem, as far as I could figure out. A format c:/ > > doesn't erase UEFI... > > Formatting a Linux disk partition also doesn't change anything in the > EFI NVRAM. Linux (the kernel) provides a filesystem interface to the > EFI variable services. And this (pseudo-)filesystem defines an unlink > operation which performs a 'delete EFI variable' operation. On the > surface, that's not an unreasonable implementation idea although one > could argue that exposing these variables in the filesystem such that > recursive filesystem operations like 'rm -r' can hit them would be > overly risky. > > > Dear Rainer, I know that. We all know that. You're right. I'm only looking for a way out of a discussion that will not bare fruit. The smart people on this list should be able to pick up minor errors like this (that have in itself nothing to do with Devuan) and come out with a simple fix as being better-than-the-rest. As I wrote before, a recent test on an old laptop showed that all Linux installers I tried failed miserably. Only freeBSD succeeded. An average user will see this as a victory for FreeBSD. We know better. It's not as simple and different hardware will yield different results. I am praying for Devuan to be the winner. Not just another distro, existing because we don't like systemd. Debian is/was a fine starting point. It has served me well for over ten years. Let's make it better! Wim ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
On Thu, 4 Feb 2016 09:36:05 + Simon Hobson wrote: > Trash the OS - fair game (maybe). Brick the hardware, that's another > kettle of fish. Another (and consistent) view is that we had a deal. From 1969 til 2013, we had a deal that if you backed up every day and then used a bad rf command, restoration to the beginning of the day would be a couple hours of work, and that's it. Now, when you ill-advisably use rm, you need to go out and buy, then configure, a totally new machine, before you can even begin to restore from backup. And be careful: /dev/sda1 might not be the same on the new box. SteveT Steve Litt February 2016 featured book: The Key to Everyday Excellence http://www.troubleshooters.com/key ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
Wim writes: [...] > I'd like to see Devuan do better. Better than Debian, fi. Windows doesn't > seem to have this problem, as far as I could figure out. A format c:/ > doesn't erase UEFI... Formatting a Linux disk partition also doesn't change anything in the EFI NVRAM. Linux (the kernel) provides a filesystem interface to the EFI variable services. And this (pseudo-)filesystem defines an unlink operation which performs a 'delete EFI variable' operation. On the surface, that's not an unreasonable implementation idea although one could argue that exposing these variables in the filesystem such that recursive filesystem operations like 'rm -r' can hit them would be overly risky. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
2016-02-04 17:55 GMT+01:00 Simon Hobson : > Rainer Weikusat wrote: > > > "Whoever disagrees with me MUST either have a hidden, maliscious agenda > > or be out of his mind" is a pretty standard way to (attempt to) handle > > a situation where someone ran out of arguments but doesn't feel like > > admitting that. > > Not at all. I have a perfectly sound argument. You are stubbornly trolling > that users deserve to have their hardware bricked. > I know you won't accept that, but all your arguments come down to "no > protection, the user is responsible, if he makes a mistake then tough". I, > and others, are of the opinion that there are quite reasonable measures > that could be made the default which a) wouldn't break anything in a way > that wasn't easy to deal with*, and b) would provide "reasonable" > protection against the problem. > > Since you are so certain that documentation is sufficient, can you show me > in the man page for "rm" where it mentions the possibility of bricking the > hardware ? > > > > * As in, yes we understand it breaks X, there's a genuine reason for doing > it, but here are ways to fix that. As opposed to certain camps where "we > don't care what get broken and it's nothing to do with us to solve it" > seems to be the mantra. > Boys, Maybe we can agree to disagree? I'd like to see Devuan do better. Better than Debian, fi. Windows doesn't seem to have this problem, as far as I could figure out. A format c:/ doesn't erase UEFI... While this is mostly a fault by the manufacturer of the hardware, there seem to be a lot of those machines around. It's not Devuan's task to fix those, but if we can at least warn the user, or prevent the mishap, why shouldn't we? Just my 2 cents. Wim ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
Simon Hobson writes: > Rainer Weikusat wrote: > >> "Whoever disagrees with me MUST either have a hidden, maliscious agenda >> or be out of his mind" is a pretty standard way to (attempt to) handle >> a situation where someone ran out of arguments but doesn't feel like >> admitting that. > > Not at all. I have a perfectly sound argument. You are stubbornly > trolling that users deserve to have their hardware bricked. I never wrote "users deserve ot have their hardware bricked". That's another generalization you invented. Apart from that, none of your snide remarks about me is even remotely related to the topic under discussion. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
Rainer Weikusat wrote: > "Whoever disagrees with me MUST either have a hidden, maliscious agenda > or be out of his mind" is a pretty standard way to (attempt to) handle > a situation where someone ran out of arguments but doesn't feel like > admitting that. Not at all. I have a perfectly sound argument. You are stubbornly trolling that users deserve to have their hardware bricked. I know you won't accept that, but all your arguments come down to "no protection, the user is responsible, if he makes a mistake then tough". I, and others, are of the opinion that there are quite reasonable measures that could be made the default which a) wouldn't break anything in a way that wasn't easy to deal with*, and b) would provide "reasonable" protection against the problem. Since you are so certain that documentation is sufficient, can you show me in the man page for "rm" where it mentions the possibility of bricking the hardware ? * As in, yes we understand it breaks X, there's a genuine reason for doing it, but here are ways to fix that. As opposed to certain camps where "we don't care what get broken and it's nothing to do with us to solve it" seems to be the mantra. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
On Thu, 04 Feb 2016 14:44:48 +, Rainer wrote in message <87k2mka61r@doppelsaurus.mobileactivedefense.com>: > Didier Kryn writes: > > Le 04/02/2016 13:07, Rainer Weikusat a écrit : > >> for the real "general case", > >> someone who blindly trusts the advice of strangers despite he > >> doesn't understand it will end up getting himself in trouble > >> sooner or later and probably rather sooner than later. > > > > Eg nearly any client of a physician, a lawyer... > > The context of my statement was > > , > | We're talking about the general case, where the "maybe not such a > | command line guru" is googling for suggestions and comes across the > | "you can do X by X" answer somewhere. The answer was probably > written | prior to this UEFI mounted filesystem stuff, the user > probably doesn't | understand what half the things returned by mount > our, and uses a | command that supposedly achieves what he needs. > ` > > I hope you're a bit more careful when taking medical or legal advice. ...or financial advice... if you can afford it. ;o) What do banks run these days? ;oD -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
Didier Kryn writes: > Le 04/02/2016 13:07, Rainer Weikusat a écrit : >> for the real "general case", >> someone who blindly trusts the advice of strangers despite he doesn't >> understand it will end up getting himself in trouble sooner or later and >> probably rather sooner than later. > > Eg nearly any client of a physician, a lawyer... The context of my statement was , | We're talking about the general case, where the "maybe not such a | command line guru" is googling for suggestions and comes across the | "you can do X by X" answer somewhere. The answer was probably written | prior to this UEFI mounted filesystem stuff, the user probably doesn't | understand what half the things returned by mount our, and uses a | command that supposedly achieves what he needs. ` I hope you're a bit more careful when taking medical or legal advice. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
Simon Hobson writes: > Didier Kryn wrote: > >>> for the real "general case", >>> someone who blindly trusts the advice of strangers despite he doesn't >>> understand it will end up getting himself in trouble sooner or later and >>> probably rather sooner than later. >> >>Eg nearly any client of a physician, a lawyer... > > :-) > > It's hard to work out whether Rainer is trolling or just really out of > touch with the real world. "Whoever disagrees with me MUST either have a hidden, maliscious agenda or be out of his mind" is a pretty standard way to (attempt to) handle a situation where someone ran out of arguments but doesn't feel like admitting that. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
Didier: > Le 04/02/2016 13:07, Rainer Weikusat a écrit : > > for the real "general case", > > someone who blindly trusts the advice of strangers despite he doesn't > > understand it will end up getting himself in trouble sooner or later and > > probably rather sooner than later. > Eg nearly any client of a physician, a lawyer... Yes, absolutely. If you don't know the field and don't check the advice you get, you are in for trouble. Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
Didier Kryn wrote: >> for the real "general case", >> someone who blindly trusts the advice of strangers despite he doesn't >> understand it will end up getting himself in trouble sooner or later and >> probably rather sooner than later. > >Eg nearly any client of a physician, a lawyer... :-) It's hard to work out whether Rainer is trolling or just really out of touch with the real world. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
Le 04/02/2016 13:07, Rainer Weikusat a écrit : for the real "general case", someone who blindly trusts the advice of strangers despite he doesn't understand it will end up getting himself in trouble sooner or later and probably rather sooner than later. Eg nearly any client of a physician, a lawyer... Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
Simon Hobson writes: > Rainer Weikusat wrote: >> Dave Turner writes: >>> There seems to be an assumption that everybody is a 'power user' and >>> knows exactly what they are doing. >>> The reality is not like that at all. >>> Leaving nasty surprises for the unwary and inexperienced is at worst >>> malicious and at best incompetent. >> >> How does this apply to someone who executed a command "because he wanted >> to watch GNOME die" after "he unmounted all important filesystem" or - >> more accurately - wrongly believed to have done so? >> >>> I would guess that most of us here have googled for the answer to some >>> programming or scripting conundrum, and how many stackoverflow etc >>> answers did you have to go through to find an answer that was correct? >>> Far too many. >> >> How does this apply to the situation? >> >>> Now imagine the poor sod new to all this... It is most emphatically >>> not gross neglect on the part of the user. >> >> The 'poor sod' wasn't "new to all of this". > > Now I understand your hostility to the idea of trying to provide some > safety "Provide some safety" is a far to general statement for anyone to have any opinion on it. > - you are assuming we are **ONLY** talking about the person who did > this deliberately. I was only making statements about this situation. > We're talking about the general case, where the "maybe not such a > command line guru" is googling for suggestions and comes across the > "you can do X by X" answer somewhere. The answer was probably written > prior to this UEFI mounted filesystem stuff, the user probably doesn't > understand what half the things returned by mount our, and uses a > command that supposedly achieves what he needs. That's a fictional situation, however, for the real "general case", someone who blindly trusts the advice of strangers despite he doesn't understand it will end up getting himself in trouble sooner or later and probably rather sooner than later. But that's somewhat besides the point here. [...] > Say you read the man pages and release notes for "rm" - will you find > a warning that it can brick your UEFI hardware ? Doubt it ! A nice idea for a comical horror movie scene I had a while ago was someone killing someone else by strapping him to a table and hammering a pair of carrots through the eyes into his brain (don't know if this is really possible with carrots but it should surely work with screwdrivers) with his fists while screaming madly. With the camera moving backwards at the end of the scene from a perpsective where on can see the top of the head of the killed guy, ie, level with the table, with the carrots sticking out. But I never found a warning about that on any carrot I bought. Unlinking all files and directories on a mounted pseudo-filesystem can have a completely arbitrary effect, ie, it's not "rm bricking the UEFI hardware" but a certain kernel driver modifying the UEFI NVRAM as instructed by a user. One could argue that a different interface than the filesystem namespace would be more appropriate here. I have no opinion on that because I know too little about 'EFI variables' but in this case, your (or anyone else's) would be beef with the kernel code implementing the interface and not with systemd using it. [...] > Even if someone runs rm -rf /, while the command takes some time - the > actual window for it to catch the UEFI fs during a "write enable, > modify, write protect" task is still fairly small. Let me put it this way: Were I the author of some software acting in this way, I wouldn't allow you to use it for anything unless you've given me a written declaration that you won't hold me responsible if it destroys your hardware without even giving you a chance to prevent that. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
Peter Vachuska writes: [...] > And I still don't understand why one would want a switch that bricks > your computer? It's easier to punish it this way than physically smashing it to bits. But there was no such switch involved here. Just a non-volatile RAM whose contents can be modified (that's the point of it) and someone who deleted the contents "by accident" or at least claimed that he did so. The circumstances don't look entirely probable to me. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
Le 03/02/2016 22:29, Peter Vachuska a écrit : 03.02.2016, 14:56, "Steve Litt" : Let's talk about a minimal standard of safety as opposed to relying on "knowing what you're doing." A little knowledge is a dangerous thing. I wouldn't have hesitated using 'rm -rf /' if I was going to remove all of the files from my current installation and reinstall anew. And I still don't understand why one would want a switch that bricks your computer? AFAIU (and I'd sincerely like to read a confimation or rebutal), Grub updates need to write to this pseudo filesystem; hence the idea to turn the switch on during this upgrade and let it off the rest of the time. Otherwise I wouldn't see the purpose of even mounting the thing at all. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
Rainer Weikusat wrote: > Dave Turner writes: >> There seems to be an assumption that everybody is a 'power user' and >> knows exactly what they are doing. >> The reality is not like that at all. >> Leaving nasty surprises for the unwary and inexperienced is at worst >> malicious and at best incompetent. > > How does this apply to someone who executed a command "because he wanted > to watch GNOME die" after "he unmounted all important filesystem" or - > more accurately - wrongly believed to have done so? > >> I would guess that most of us here have googled for the answer to some >> programming or scripting conundrum, and how many stackoverflow etc >> answers did you have to go through to find an answer that was correct? >> Far too many. > > How does this apply to the situation? > >> Now imagine the poor sod new to all this... It is most emphatically >> not gross neglect on the part of the user. > > The 'poor sod' wasn't "new to all of this". Now I understand your hostility to the idea of trying to provide some safety - you are assuming we are **ONLY** talking about the person who did this deliberately. We're talking about the general case, where the "maybe not such a command line guru" is googling for suggestions and comes across the "you can do X by X" answer somewhere. The answer was probably written prior to this UEFI mounted filesystem stuff, the user probably doesn't understand what half the things returned by mount our, and uses a command that supposedly achieves what he needs. If you are telling me that you have never *EVER* had to search for a command to do something, and used it without understanding 101% how and why it works, and what any ramifications are, and read all the release notes for everything that can possibly be affected by it - then I suggest you memory is a bit lacking. Say you read the man pages and release notes for "rm" - will you find a warning that it can brick your UEFI hardware ? Doubt it ! Trash the OS - fair game (maybe). Brick the hardware, that's another kettle of fish. What we are talking about is the "average user" (not that there is such a thing) finding he's bricked his hardware because of a combination of buggy crapware (UEFI) and a stupid design decision with other buggy crapware) to expose that first buggy crapware to being crapped upon. Even if someone runs rm -rf /, while the command takes some time - the actual window for it to catch the UEFI fs during a "write enable, modify, write protect" task is still fairly small. And for that to work the admin would need to do something that's going to hose the OS, and while that's running, from another terminal/console run another command that's going to update it's config. And the timing needs to be spot on within a few seconds at most. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
03.02.2016, 14:56, "Steve Litt" : > > Let's talk about a minimal standard of safety as opposed to relying on > "knowing what you're doing." > A little knowledge is a dangerous thing. I wouldn't have hesitated using 'rm -rf /' if I was going to remove all of the files from my current installation and reinstall anew. And I still don't understand why one would want a switch that bricks your computer? -peter ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
Dave Turner writes: > There seems to be an assumption that everybody is a 'power user' and > knows exactly what they are doing. > The reality is not like that at all. > Leaving nasty surprises for the unwary and inexperienced is at worst > malicious and at best incompetent. How does this apply to someone who executed a command "because he wanted to watch GNOME die" after "he unmounted all important filesystem" or - more accurately - wrongly believed to have done so? > I would guess that most of us here have googled for the answer to some > programming or scripting conundrum, and how many stackoverflow etc > answers did you have to go through to find an answer that was correct? > Far too many. How does this apply to the situation? > Now imagine the poor sod new to all this... It is most emphatically > not gross neglect on the part of the user. The 'poor sod' wasn't "new to all of this". ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
There seems to be an assumption that everybody is a 'power user' and knows exactly what they are doing. The reality is not like that at all. Leaving nasty surprises for the unwary and inexperienced is at worst malicious and at best incompetent. I would guess that most of us here have googled for the answer to some programming or scripting conundrum, and how many stackoverflow etc answers did you have to go through to find an answer that was correct? Far too many. Now imagine the poor sod new to all this... It is most emphatically not gross neglect on the part of the user. And don't get me started on RTFM! If I knew where the authors of some crappy man pages lived I would burn their house down. DaveT On 03/02/16 21:39, Rainer Weikusat wrote: Steve Litt writes: Rainer Weikusat wrote: There are really only two options: 1. Don't mount or mount r/o and require user interfaction prior to working with these variables. 2. Mount r/w and expect people messing around with the fs as superuser to know what they're doing. [another misused analogy] In a Poettering/UEFI world, railings are all less than 2 feet high, high rise picture windows are large and low, mountain roads have no guard rails on curves, bridge abutments have no sand barrels in front of them, and people who draw blood don't wear rubber gloves. We all know what we're doing, and if something goes wrong, we deserve what we get. None of these statements is applicable to the situation. This was about first intentionally executing a command supposed to delete everything accessible via any some mounted filesystem and then 'discovering' that this command deleted some things which should rather have been kept. Executing such a command without knowing which filesystems are mounted and how this will affect the state of the machine is not "an unfortunate accident" but simply gross neglect. Regarding the different-but-related issue of 'buggy software' causing the deletion, there should be a prominent "policy choice" to prevent any modification of 'EFI variables' unless a user specifically oks that. That's also something where the "systemd responses" of "our convenience beats your hardware" (as we make the descisions) is clearly wanting. But that's because users are supposed to be in control of their hardware/ software and not because random morons "want to watch GNOME die". ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
Steve Litt writes: > Rainer Weikusat wrote: > >> There are really only two options: >> >> 1. Don't mount or mount r/o and require user interfaction prior to >>working with these variables. >> >> 2. Mount r/w and expect people messing around with the fs as superuser >>to know what they're doing. [another misused analogy] > In a Poettering/UEFI world, railings are all less than 2 feet high, > high rise picture windows are large and low, mountain roads have no > guard rails on curves, bridge abutments have no sand barrels in front > of them, and people who draw blood don't wear rubber gloves. We all > know what we're doing, and if something goes wrong, we deserve what we > get. None of these statements is applicable to the situation. This was about first intentionally executing a command supposed to delete everything accessible via any some mounted filesystem and then 'discovering' that this command deleted some things which should rather have been kept. Executing such a command without knowing which filesystems are mounted and how this will affect the state of the machine is not "an unfortunate accident" but simply gross neglect. Regarding the different-but-related issue of 'buggy software' causing the deletion, there should be a prominent "policy choice" to prevent any modification of 'EFI variables' unless a user specifically oks that. That's also something where the "systemd responses" of "our convenience beats your hardware" (as we make the descisions) is clearly wanting. But that's because users are supposed to be in control of their hardware/ software and not because random morons "want to watch GNOME die". ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
On Tue, 02 Feb 2016 20:07:33 + Rainer Weikusat wrote: > There are really only two options: > > 1. Don't mount or mount r/o and require user interfaction prior to >working with these variables. > > 2. Mount r/w and expect people messing around with the fs as superuser >to know what they're doing. Let's talk about a minimal standard of safety as opposed to relying on "knowing what you're doing." The following is a story about a woman who pushed her husband out their 25th floor window, either accidentally, negligently, or with motive to kill: http://tinyurl.com/z6vj3eq http://www.dailymail.co.uk/news/article-2293486/Amber-Hilberling-murder-trial-Wife-says-bushing-Air-Force-husband-17th-floor-window-accident.html And here's a photo of a similar window in the building: http://i.dailymail.co.uk/i/pix/2013/03/14/article-2293486-18AB5EAB05DC-906_634x337.jpg A window going from somewhere between 2 and 3 feet off the floor, proceeding to about 6 feet off the ground. No railings, no crossbeams, no patio outside. If a normal sized adult hit that window hard enough to break it, he/she would fall to his/her death. I take no stand to the woman's guilt or innocence or motivation, but looking at that room, it would immediately strike me as dangerous. I'm surprised more inhabitants of that building haven't fallen to their deaths. We all know what we're doing, but sometimes there's an accident. You're having a tug of war with your 100 pound dog, the dog lets go, and you go right out the window. In a Poettering/UEFI world, railings are all less than 2 feet high, high rise picture windows are large and low, mountain roads have no guard rails on curves, bridge abutments have no sand barrels in front of them, and people who draw blood don't wear rubber gloves. We all know what we're doing, and if something goes wrong, we deserve what we get. SteveT Steve Litt February 2016 featured book: The Key to Everyday Excellence http://www.troubleshooters.com/key ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
Boruch Baum writes: > Can anyone answer: > > 1] Does this vulnerability apply when the UEFI is operating in "legacy > boot" mode instead of "secure boot" mode? I recall that when I was > originally setting up my only UEFI-equipped device that there were > differences between the two modes in how I needed to set up the > partition table. This isn't really a "vulnerability". It's an API for performing certain operations and some of the operations one can perform in this way reportedly interact very badly with buggy firmware. 'Legacy boot mode' should usually mean 'use a/the BIOS' instead of 'use UEFI' (that's at least what it meant on my computer) hence, it should sidestep the issue. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
Rainer Weikusat writes: > Simon Hobson writes: [...] >> Just mounting r/w leaves us with the problem as already described. > > I see no problem with this Addition: IMHO, this should be a system-wide policy descision someone should consciously make during setup, ie, mount it r/w and then "stuff just works" but errant commands can damage things or mount it r/o and take care that it becomes r/w whenever and for as long as needed. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
Simon Hobson writes: > Rainer Weikusat wrote: > >>> Or the third option - mount r/o and remount r/w when needed. >> >> As I wrote in the original text, that's a extremely bad idea because >> this means it may suddenly be affected by an already running command >> never supposed to work with it. > > The window for that must be "very small". Yes I know about TOCTOU > issues, but unless a command has a long execution time, then it's got > to run during "just" the small window between the fs being made r/w > and it being made r/o again - typically a few seconds. rm -rf / will have a long execution time. But that's besides the point: The guy who killed his laptop could have avoided that. With an "remount whenever systemd feels like that" mechanism, nobody can anymore. > Requiring user intervention (ie making it writeable) has just the same > problem - except that the window is very much longer. It doesn't. In this case, someone administrating the machine has been informed (at least) about the fact that such-and-such a filesystem will become writeable until and that someone can coordinate his activities with those of other people, including his own. > Just mounting r/w leaves us with the problem as already described. I see no problem with this except the cultural problem that "GUI people" are accustomed to being able to press random buttons in random sequences while always being stopped by a child-proof lock before anyhing actually happens[*]. And nothing which hasn't been computerized works in this way: If I turn my stove on, the burners get hot despite this is a seriously dangerous device when used incorrectly. [*] Coincidentally, the same people usually prefer household appliances to be operated by less fumble-happy "expert technicians". ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
Simon Hobson escribió: [...] - remounts as r/w - runs the command - remounts as r/o [...] 2) Prompt the user that this needs to be done (perhaps with warnings about other stuff accessing the fs), and ask for confirmation before doing it. [...] This sounds as the best way to go, in almost any case. regards Noel er Envite binJk6zju00jr.bin Description: Clave PGP pública pgpRriV97Lcmn.pgp Description: Firma digital PGP ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
Rainer Weikusat wrote: >> Or the third option - mount r/o and remount r/w when needed. > > As I wrote in the original text, that's a extremely bad idea because > this means it may suddenly be affected by an already running command > never supposed to work with it. The window for that must be "very small". Yes I know about TOCTOU issues, but unless a command has a long execution time, then it's got to run during "just" the small window between the fs being made r/w and it being made r/o again - typically a few seconds. Requiring user intervention (ie making it writeable) has just the same problem - except that the window is very much longer. Not to mention, the risk of forgetting to "lock the door" again afterwards. Just mounting r/w leaves us with the problem as already described. So IMO, of the options presented, remounting as required would seem (to me) to be the least bad. One way I could see it being done (and avoiding the need to modify exiting utils) would be to provide a wrapper which : - remounts as r/w - runs the command - remounts as r/o The wrapper can be made as simple or complicated as wanted - and could, for example, do one of several things : 1) Prompt the user that the fs needs to be remounted r/w and wait for the user to do it 2) Prompt the user that this needs to be done (perhaps with warnings about other stuff accessing the fs), and ask for confirmation before doing it. 3) Have a config option to assume a "yes" response to option 2) - in much the same way as the -y or --force flag on so many utilities. Option 3) puts the choice in the hands of the admin - it's up to him to set the option, and if the config file is suitably commented then that also deals with the "inform the user of the problem" aspect that no amount of release notes etc will cover. I think we all agree that as long as there are EFI systems that are broken in this way, then there is no "100% safe" way around it - just varying degrees of "least bad". ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
Steve Litt writes: > Rainer Weikusat wrote: >> There are really only two options: >> > [snip] >> >> 2. Mount r/w and expect people messing around with the fs as superuser >>to know what they're doing. > > Chefs know what they're doing, but they still have fire extinguishers > with which to put out any fires. If there's a fire extinguisher in a kitchen then because the guy who runs the establishment won't get an insurance otherwise. On it's own, he'd very likely rather avoid the expense based on "it ain't gonna happen" (and in case it does, he'll complain to the builder because "Why did this have to be flammable ? Didn't you realize this meant it will burn ?!? This is entirely your fault !!! I want my money back " even if only because there's at least a slight chance that this might work). Silly jokes about the analogy aside, I don't see why it would apply here. The case in point was someone intentionally running rm -rf / because he was convinced this would only damage stuff he wanted to damage. This means he either didn't bother to check which filesystems where actually mounted or wrongly assumed that deleting everything made available by them would be harmless. One could argue that exposing EFI variables in the filesystem in this way is not a good idea but this would then apply to the code providing this API and not the code which pretty much has to use it. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
Simon Hobson writes: > Rainer Weikusat wrote: > >> There are really only two options: >> >> 1. Don't mount or mount r/o and require user interfaction prior to >> working with these variables. >> >> 2. Mount r/w and expect people messing around with the fs as superuser >> to know what they're doing. > > Or the third option - mount r/o and remount r/w when needed. As I wrote in the original text, that's a extremely bad idea because this means it may suddenly be affected by an already running command never supposed to work with it. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
Simon Hobson writes: Or the third option - mount r/o and remount r/w when needed. IIRC you can switch an already mounted filesystem from r/o to r/w 'on the fly' (ie without unmounting it first) - is the reverse possible (ie change a r/w mount to r/o) ? Yes. mount -o remount,ro. I've done that more than once on android (remounting like that is how you get rid of the tasteless and/or annoying boot animations most vendors like). Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
Rainer Weikusat wrote: > There are really only two options: > > 1. Don't mount or mount r/o and require user interfaction prior to > working with these variables. > > 2. Mount r/w and expect people messing around with the fs as superuser > to know what they're doing. Or the third option - mount r/o and remount r/w when needed. IIRC you can switch an already mounted filesystem from r/o to r/w 'on the fly' (ie without unmounting it first) - is the reverse possible (ie change a r/w mount to r/o) ? Given that it's only a very very small number of programs that actually need this ability, it does seem that the "sensible" way is to make those few programs do a tiny bit of extra work and make the system safe. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
Steve Litt [2016-02-02 22:39]: > Chefs know what they're doing, but they still have fire extinguishers > with which to put out any fires. When the downside is severe enough, > safety measures are called for regardless of the skill of the operator. Amen! -- Hilsen Harald ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
Can anyone answer: 1] Does this vulnerability apply when the UEFI is operating in "legacy boot" mode instead of "secure boot" mode? I recall that when I was originally setting up my only UEFI-equipped device that there were differences between the two modes in how I needed to set up the partition table. 2] If this vulnerability is exploited, is there a JTAG fix? I haven't looked at my particular motherboard, but many have a physical access JTAG connector with which to directly access/debug/modify firmware on the board. -- hkp://keys.gnupg.net CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0 signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
On Tue, Feb 02, 2016 at 04:39:57PM -0500, Steve Litt wrote: > On Tue, 02 Feb 2016 20:07:33 + > Rainer Weikusat wrote: > > > There are really only two options: > > > [snip] > > > > 2. Mount r/w and expect people messing around with the fs as superuser > >to know what they're doing. > > Chefs know what they're doing, but they still have fire extinguishers > with which to put out any fires. When the downside is severe enough, > safety measures are called for regardless of the skill of the operator. > In this case the stupid design is not to be blamed, but maybe the (missing of proper) documentation of such silly behaviour is the real culprit. I don't excuse people for not knowing that they can damage their system, *if* they have been given the opportunity to acquire the necessary knowledge about that issue. Then, I have to say that I personally find it still very stupid to give the possibility to brick a laptop without putting large blinking red signs of warning everywhere, to specify that there is this risk. My2Cents KatolaZ -- [ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ] [ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ] [ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ] [ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ] ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
On Tue, 02 Feb 2016 20:07:33 + Rainer Weikusat wrote: > There are really only two options: > [snip] > > 2. Mount r/w and expect people messing around with the fs as superuser >to know what they're doing. Chefs know what they're doing, but they still have fire extinguishers with which to put out any fires. When the downside is severe enough, safety measures are called for regardless of the skill of the operator. SteveT Steve Litt February 2016 featured book: The Key to Everyday Excellence http://www.troubleshooters.com/key ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
Steve Litt writes: > On Tue, 2 Feb 2016 10:49:10 +0100 Jaromil wrote: > >> On Tue, 02 Feb 2016, Wim wrote: >> >> >[2]https://github.com/systemd/systemd/issues/2402 >> >Well, you've probably guessed the answer - Won't fix. >> >> meanwhile, on the background, the usual bullying goes on among the >> systemd hooligans, sarcastically liquidating the concern with some >> cynical remarks, as if it would be a deserved punition for users >> caught into a bricked laptop rather than an erased filesystem: > > I think I've established my bone-fides as a systemd hater, and > Poettering's decision to leave this thing read/write instead of > having it r/o and having his utilities rw/change/ro is just typical > Freedesktop/Redhat/Poettering nonsense, Considering that the way to access this so-called 'variables' is via the filesystem namespace, that would be a horrendous mistake: This would imply they could be affected 'on the fly' by a command never supposed to work with them because the filesystem happened to be mounted (or to be remounted) at the right time while the command was running. There are really only two options: 1. Don't mount or mount r/o and require user interfaction prior to working with these variables. 2. Mount r/w and expect people messing around with the fs as superuser to know what they're doing. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
The proposed fix is to mark it in fstab as read only... I was under the impression fstab was one of the things systemd wanted to replace/eradicate? 2016-02-02 16:15 GMT+01:00 Fernando M. Maresca : > On Tue, Feb 02, 2016 at 10:07:17AM -0500, Steve Litt wrote: > > Back in the BIOS/MBR days, we had a very thin, very tiny interface to > > the pre-boot stuff. About the only way you could mess it up was to blow > > a bios upgrade, so you were always *very* careful during that process. > > But in every other respect with BIOS/MBR, nothing you could do in > > software could damage your hardware. > > > > BIOS/MBR had a very thin interface. > > > > Now comes UEFI, with this huge interface, to its pre-boot firmware and > > non-volatile RAM, intended to be accessed by run of the mill > > application programs and even commands typed in at the command prompt. > > How is this exposure of many different "EFI variables" to every > > possible software on the system different from systemd's spaghetti web > > of dependencies? > > > > Answer: It's not. It's one more case of abdication of modularity. > > +1 > > -- > Fernando M. Maresca > - - - - - - - - - - - - - > Cel: 221 15 545 8196 > Tel: 221 450 5378 > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng > ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
On Tue, Feb 02, 2016 at 10:07:17AM -0500, Steve Litt wrote: > Back in the BIOS/MBR days, we had a very thin, very tiny interface to > the pre-boot stuff. About the only way you could mess it up was to blow > a bios upgrade, so you were always *very* careful during that process. > But in every other respect with BIOS/MBR, nothing you could do in > software could damage your hardware. > > BIOS/MBR had a very thin interface. > > Now comes UEFI, with this huge interface, to its pre-boot firmware and > non-volatile RAM, intended to be accessed by run of the mill > application programs and even commands typed in at the command prompt. > How is this exposure of many different "EFI variables" to every > possible software on the system different from systemd's spaghetti web > of dependencies? > > Answer: It's not. It's one more case of abdication of modularity. +1 -- Fernando M. Maresca - - - - - - - - - - - - - Cel: 221 15 545 8196 Tel: 221 450 5378 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Bad UEFI: was Systemd at work: rm -rf EFI
On Tue, 2 Feb 2016 10:49:10 +0100 Jaromil wrote: > On Tue, 02 Feb 2016, Wim wrote: > > >[2]https://github.com/systemd/systemd/issues/2402 > >Well, you've probably guessed the answer - Won't fix. > > meanwhile, on the background, the usual bullying goes on among the > systemd hooligans, sarcastically liquidating the concern with some > cynical remarks, as if it would be a deserved punition for users > caught into a bricked laptop rather than an erased filesystem: I think I've established my bone-fides as a systemd hater, and Poettering's decision to leave this thing read/write instead of having it r/o and having his utilities rw/change/ro is just typical Freedesktop/Redhat/Poettering nonsense, but I want to make sure nobody loses sight of the real culprit here: UEFI. Back in the BIOS/MBR days, we had a very thin, very tiny interface to the pre-boot stuff. About the only way you could mess it up was to blow a bios upgrade, so you were always *very* careful during that process. But in every other respect with BIOS/MBR, nothing you could do in software could damage your hardware. BIOS/MBR had a very thin interface. Now comes UEFI, with this huge interface, to its pre-boot firmware and non-volatile RAM, intended to be accessed by run of the mill application programs and even commands typed in at the command prompt. How is this exposure of many different "EFI variables" to every possible software on the system different from systemd's spaghetti web of dependencies? Answer: It's not. It's one more case of abdication of modularity. In the old days, you could do *anything* in the user or kernel space, confident that nothing you did touched the pre-boot. Now, preboot and OS are welded together. And what you get is the same: Hard to troubleshoot because you can't tell who talked to whom. And in the case of UEFI, the very real likelihood of hardware destruction. Yeah, MBR was getting old and perhaps needed replacement. But UEFI is a step down from the 30 year old MBR. Hey, where have I heard that logic before? SteveT Steve Litt February 2016 featured book: The Key to Everyday Excellence http://www.troubleshooters.com/key ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
