linux-ext4 - Re: [PATCH v4] Add ioctls to get/set the ext4 superblock uuid.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 20 Jul 2022 10:59:35 -0400
From:   "Theodore Ts'o" <tytso@....edu>
To:     "Darrick J. Wong" <djwong@...nel.org>
Cc:     Matthew Wilcox <willy@...radead.org>,
        Jeremy Bongio <bongiojp@...il.com>, linux-ext4@...r.kernel.org,
        linux-api@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH v4] Add ioctls to get/set the ext4 superblock uuid.

On Tue, Jul 19, 2022 at 08:30:57PM -0700, Darrick J. Wong wrote:
> 
> @len because some filesystems like vfat have volume identifiers that
> aren't actually UUIDs (they're u32)...

It's not just vfat.  Ntfs uses a 64-bit volume identifier, and we
still see both vfat and ntfs on modern-day laptops.  For example, on
my Samsung Galaxy Pro 360, purchased earlier this year and which uses
Secure UEFI boot to dual boot Windows and Debian Linux:

% sudo blkid
/dev/nvme0n1p7: UUID="915eb577-a05d-48ba-ad66-346e14908d19" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="3194abab-3fe6-4b59-960f-95806d27b1cd"
/dev/nvme0n1p5: LABEL="SAMSUNG_REC" UUID="0A64-BC1B" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="Basi" PARTUUID="441e92c9-d55b-40ec-4173-636c65706975"
/dev/nvme0n1p3: LABEL="Windows RE tools" BLOCK_SIZE="512" UUID="F49088359087FC7C" TYPE="ntfs" PARTLABEL="M-fM-%M-^WM-fM-^QM-.M-gM-^]M-/M-bM-^AM-3" PARTUUID="0cc7d7ec-6481-40b9-bf23-83b889f020e2"
/dev/nvme0n1p1: LABEL_FATBOOT="SYSTEM" LABEL="SYSTEM" UUID="345B-0F8C" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="EFI" PARTUUID="13bbf92c-8e02-41fb-93a4-9c4c8328d08a"
/dev/nvme0n1p8: UUID="929a1920-e84c-4797-98b1-2d719e64388f" TYPE="swap" PARTUUID="8d2aad9d-f7a9-47a1-8729-9de367d44696"
/dev/nvme0n1p6: BLOCK_SIZE="512" UUID="82A25B9DA25B950F" TYPE="ntfs" PARTUUID="89bfd94a-3c21-44df-9d6e-c2e66ae1a3ec"
/dev/nvme0n1p4: LABEL="SAMSUNG_REC2" BLOCK_SIZE="512" UUID="A24E62F14E62BDA3" TYPE="ntfs" PARTLABEL="M-fM-^UM-^RM-fM-=M-#M-fM-^UM-6M-gM-%M-2" PARTUUID="9cd299e0-4454-430a-9e96-54ccbf250ff8"

Also note that for better or worse, historically blkid has always
treeated the VFAT and NTFS volume id's as "UUID's", since they serve
the same purpose as UUID's on ext2/ext4/xfs file systems, and so
people may very well have /etc/fstab files which specify a volume by
their UUID:

# /boot/efi was on /dev/nvme0n1p1 during installation
UUID=345B-0F8C  /boot/efi       vfat    umask=0077      0       1

Perhaps a purist would have insisted that we have used "FSVOLID"
instead of "UUID" in blkid almost 20 years ago, in which case perhaps
these ioctl's would have been named FS_IOC_[GS]ETFSVOLID.  But at this
point, it's clearer if we stick with FS_IOC_GETUUID than to try to
introduce change the naming scheme at this point.

					- Ted