25 Feb
2021
25 Feb
'21
12:48 a.m.
On 2/24/21 11:37 AM, Theodore Ts'o wrote:
Oh, sure. I agree completely that it's 180
degrees from the original
golden rule; it had intended to be a joke. Unfortunately, years of
living in a country whre the ones with the Gold really do make all
of the Rules has gotten me to the point where if I don't laugh at it,
I would have to cry....
When colleagues would say "you would think" or "I've been
thinking" or
the likes, with "We don't do that! The logo does it for us!" when
dealing with IBM shenanigans. Again, laugh, lest I cry.
So technically it doesn't wipe out UEFI; it just
will destroy the
ability to boot the system. (e.g., this is where Grub lives, and if
you delete it, UEFI will no longer be able to launch Grub, and hence,
not boot Linux.)
ACK
Either way, it causes someone to have a Bad Day™.
Fortunately, if you have a rescue CD / USB Thumb
drive, it's relatively
easy to recover from this.
And now we're back towards the start of this (sub)thread of a system
being able to boot strap itself or not.
A rogue rm which deletes /bin (even if /bin is a
symlink to /usr/bin,
all of the shell scripts and /etc/passwd entries probably still refer
to /bin/sh) is going to make the system similarly unbootable.
Agreed.
Though I think there is a difference in containing the damage to the OS
vs going beyond it and damaging the firmware configuration.
As far as making a system more robust against rogue
rm's, I really
like scheme used by ChromeOS, where the entire file system is
not only read-only, but protected by a cryptographic Merkle Tree
such that if malware attempts to modify it, the system will crash.
This is combined with firmware which will only load a kernel with a
valid digital signature, and the user data is stored on an encrypted
file system mounted on /mnt/stateful_partition and it is the only
file system mounted read/write on a ChromeOS system. It violates
a lot of expectations about where files should live on a "normal"
Unix or Linux system, but it's defnitely way more safe and secure.
I've not looked at Chrome OS or how it does things because of my dislike
for actually /using/ it. However, it sounds like it's worth popping the
hood and looking at things.
For now, as far as I know, Debian still supports a 486
(or i386 with
an i387 co-processor, which was my first Linux system). But yes,
it is very likely, absent people showing up to volunteer to support
32-bit userspace at Debian (e.g., ongoing security updates, support
for the i386 build farm, reporting and triaging build failures of
packages on i386, etc.), that the i386 arch will probably get dropped
after Debian Bullseye release (which will probably happpen sometime
in mid-2021 if I had to guess).
I don't know how quickly 32-bit will disappear. I think the embedded
market and other non-i386 32-bit platforms will likely keep 32-bit code
around for a while yet. At least user space application code. Maybe
the i386 kernel code will languish ~> bit rot. Or worse, get in the way
of maintaining 64-bit code and thereby be ejected.
I'm not sure there are any 486's around any
more, and it's likely most
uses of systems with i386 binaries are on 64-bit processors running
in 32-bit mode, so 486 vs 586 is probably not all that important in
the grand scheme of things.
¯\_(ツ)_/¯
--
Grant. . . .
unix || die