Hi Demi, On Sat, Dec 07, 2024 at 08:45:32PM GMT, Demi Marie Obenour wrote: > Is there a guarantee that if all data before the filesystem superblock is > zero, and that the filesystem never writes to this region, libblkid (and > thus, presumably, mount(8)) will always mount the filesystem with the > correct filesystem type, even if e.g. someone writes a file containing > a superblock of a different filesystem and the filesystem happens to put > it where that superblock is valid? the libblkid library offers multiple modes, with "safe mode" being the default for detecting filesystems. In this mode, the library checks for any additional valid superblocks on the device. There are exceptions for certain filesystems on CD/DVD media (such as udf and iso), but for regular filesystems, sharing the same device is not allowed. There is also an option to specify that a superblock is only valid if no other area is using it (using blkid_probe_set_wiper() and blkid_probe_use_wiper()). However, this is only used for LVM and bcache. The library does not require that there are zeros before the superblock, as not all mkfs-like programs zero out all areas. In recent years, there have been no reports of collisions. In the entire history of the library, the only collisions I can recall are with swap areas and luks, and occasionally with poorly detected FAT filesystems (due to the messy design of FAT). > The motivation for this message is that systemd-gpt-generator generates > mountpoints based on Discoverable Partition Specification GUIDs. These > indicate the mountpoint of the partition but not the filesystem type. Filesystem auto-detection is a common feature. The situation is similar to having an "auto" fstype in fstab. The systemd-gpt-generator simply identifies the partition as "/usr" (or any other mountpoint) and the rest is usual scenario. > If a correctly-produced filesystem image will always continue to be > recognized as the correct type, this is fine. Otherwise, an unlucky > combination of writes to the filesystem and filesystem allocation decisions > could cause the filesystem to start being mounted as the wrong type, which > would be very bad. According to https://github.com/util-linux/util-linux/issues/1305, > libblkid can indeed probe for subsequent superblocks after the first one it > finds. I believe the situation would be the same even without the Discoverable Partition Specification. The kernel always divides the whole disk into partitions, and libblkid/mount utilizes these partitions. Therefore, the filesystems are automatically separated by the partition table. Karel -- Karel Zak <kzak@xxxxxxxxxx> http://karelzak.blogspot.com
