Quotes of the week [LWN.net]

The structure passed is the structure abused.

Distributed systems are tricky. That's one reason I work in security, it is so much simpler.

Incidentally, many Linux filesystem implementations don't have especially robust error handling for failures during attempts to mount corrupt filesystems. As an example, I have a deliberately corrupted btrfs filesystem that triggers a BUG() if you attempt to mount it. I formatted a USB stick with this filesystem, so now I have a USB stick that will panic the kernels of distributions that support auto-mounting, in some cases even when the screen is locked.

-- Dan Rosenberg

(Log in to post comments)

Quotes of the week

Posted Feb 24, 2011 2:19 UTC (Thu) by cjb (guest, #40354) [Link]

The last quote seems to be confusing BUG() with panic(), no? Btrfs intentionally uses BUG() as a response to corruption in order to stop the damage getting worse while btrfs is still experimental. But btrfs BUG()ing doesn't "panic your kernel" as I understand the terminology; it just stops you mounting/interacting with btrfs.

Quotes of the week

Posted Feb 24, 2011 7:24 UTC (Thu) by joern (subscriber, #22392) [Link]

BUG() may not equal a kernel panic, but it will make your kernel more or less unusable. If the process held any locks before hitting BUG(), those locks will not be released. Future attempts to mount a filesystem may deadlock. Depending on the nature of the lock, write attempts on already mounted filesystem may deadlock.

I remember working on systems where BUG() would call panic(). It was considered worse to leave the system in an undefined somewhat-broken state than to give up and reboot.

Mounting needs to be a safe operation

Posted Feb 24, 2011 15:47 UTC (Thu) by epa (subscriber, #39769) [Link]

This is one reason for non-root users to be allowed to mount things (in their own directory, for devices or loopback files they own, and with nosuid,nogid,nodev of course). Once mounting a filesystem becomes a non-privileged operation, the kernel code will be forced to be more robust and not break the whole filesystem system-wide because of one corrupt device.

In other words, deliberately expose bugs in the code to a less forgiving environment, to help in the effort to fix them. I know this is a perverse approach but it can work.