Back when I was poking around with filesystem fuzzing stuff years back, I noticed something odd:
An EXT filesystem can tell the Linux OS how it should behave "if" the filesystem is corrupt, including triggering a kernel panic. In a world where USB thumb drives exist, this seems... not ideal.
Let's see what happens if we plug such a mass storage device into a fully patched Chromebook in 2024...
Oh.
Mr. Bitterness
in reply to Mr. Bitterness • • •The man page for tune2fs is pretty clear about this capability.
The person who writes the data to the USB mass storage device can specify that both:
1) The OS that reads the device should panic if the filesystem has an error.
2) The filesystem has an error.
🤦♂️
chort ↙️↙️↙️
in reply to Mr. Bitterness • • •It's funny (and rather cringe-inducing) to us infosec folks, but to 99% of developers they will always say "why would anyone do that?"
The vast majority just truly have no concept that anyone might want to act maliciously. If the engineer themself wouldn't perform a malicious action, they cannot conceive that anyone else would.
I have run into this issue so many times during my career. I now assume that no engineer will ever consider possible malicious actions taken against their code. To the extent that they do consider malicious actions, it will only be things that they themselves would do.
Mr. Bitterness
in reply to Mr. Bitterness • • •Modern Linux distros aren't really affected by this. At least in a drive-by sense. Auto-mounting is handled in a safer way than simply telling the kernel to mount the filesystem you just plugged in.
For example, compare the Ubuntu 22.04 behavior (complain that the filesystem is corrupt) vs. Ubuntu 20.04 (panic and reboot). For modern Linux to see the panic, you'd have to manually mount the filesystem (as root/sudo).
ChromeOS, on the other hand, chooses the more YOLO route of auto-mounting via the kernel.
J. "Henry" Waugh
in reply to Mr. Bitterness • • •weirdly enough, I foresaw the "logic flaw" due to weird issues with VMs and moving disks around where the policy of the source would affect the destination
I just forgot that "cause a kernel panic" was an option instead of "fail to mount/lazy unmount"
mmu_man
in reply to Mr. Bitterness • • •mirabilos
in reply to Mr. Bitterness • • •I thought that is only for errors during operation…
… let me guess, the OS is trying to access things on the fs to do things like provide icons and stats?
4censord no longer@why :neofox_sob:
in reply to Mr. Bitterness • • •bhtooefr
in reply to Mr. Bitterness • • •I can even see the use case for such a feature - if filesystem integrity is more critical than availability
but honestly, I see very little use case for a desktop operating system respecting
-e panic
, and almost no use case for anything to respect it on removable media unless explicitly opted into by the user - fall back to-e remount-ro
or unmount it IMO, but not a panic.Quixoticgeek
in reply to Mr. Bitterness • • •Cassandrich
in reply to Mr. Bitterness • • •kasperd
in reply to Mr. Bitterness • • •I remember testing that feature before I had a computer with USB. It also works with floppies.
There is a mount option which can override that behavior. If that mount option is specified the value specified on the file system itself has no effect.
It's a questionable feature. I think it would make sense to remove the ability to specify it on the file system. Having the mount option makes some kind of sense.
Bill
in reply to Mr. Bitterness • • •Adam
in reply to Mr. Bitterness • • •d33p.js
in reply to Mr. Bitterness • • •damn. I was waiting for the video to loop or precisely: the notebook stay in a panic-reboot-loop. Some minutes later: Chrome OS isnt rebooting that slowly, right?...
... no. The video just stopped. Feels like bamboozled on 9gag.
chort ↙️↙️↙️
in reply to Mr. Bitterness • • •Erik Beck
in reply to Mr. Bitterness • • •woffs
in reply to Mr. Bitterness • • •yaml nitrate
in reply to Mr. Bitterness • • •Bill, organizer of stuff
in reply to Mr. Bitterness • • •Andre
in reply to Mr. Bitterness • • •ZFS also provides a pool parameter for failmode:
failmode=wait | continue | panic
Less risk though, because USB zpools aren't automounted.
Baloo Uriza
in reply to Mr. Bitterness • • •cmars 🅅
in reply to Mr. Bitterness • • •Conan Chiles
in reply to Mr. Bitterness • • •Simon Zerafa
in reply to Mr. Bitterness • • •kirby
in reply to Mr. Bitterness • • •Nicole ‘dyfa’ Britz
in reply to Mr. Bitterness • • •Anselm "Two Sheds" Schüler
in reply to Mr. Bitterness • • •Lou 🔪🌞
in reply to Mr. Bitterness • • •Y⃒̸̷̝̜̙ͥͥͥngmar
in reply to Mr. Bitterness • • •You made a Panicstick.
I had an external hard drive that did that when plugged into my Macbook Pro, back when people still used Apple stuff. But only if I used USB 3.0. So by using a USB 2.0 cable I could avoid the panic and access my data. That was most likely a USB host bug though rather than a filesystem feature (it was using HFS+ anyways).
RedTechEngineer
in reply to Mr. Bitterness • • •Acid Bong
in reply to Mr. Bitterness • • •Matthew Garrett
in reply to Mr. Bitterness • • •mount options: Always use errors=remount-ro for ext filesystems · storaged-project/udisks@2d5d2b7
GitHubRenpona🍭Dev Vtuber
in reply to Mr. Bitterness • • •aa
in reply to Mr. Bitterness • • •rugk
in reply to Mr. Bitterness • • •Lars Wirzenius
in reply to Mr. Bitterness • • •This kind of thing is why my personal CI engine uses tar archives to get data out of the virtual machine where the CI run happens. The tar archive may be corrupt, but it it's really difficult for that to corrupt or crash the kernel.
(I know there's ways to trick software that extracts tar archives to overwrite files, and other problems, but I rely on the system tar, which is usually the GNU one, to do this well. If the system tar is vulnerable, that's a whole world of pain in itself.)
Legion495
in reply to Mr. Bitterness • • •pak0st
in reply to Mr. Bitterness • • •Zuthal
in reply to Mr. Bitterness • • •Zygmunt Krynicki
in reply to Mr. Bitterness • • •GNU/翠星石
in reply to Mr. Bitterness • • •>the Linux OS
What is this Linux OS you speak of?
After all, the kernel, Linux doesn't operate on its own and therefore it cannot possible be and *operating* system.
Chromebooks run Gentoo GNU/Linux with the freedom removed.