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 14:00:25 -0400
From:   "Theodore Ts'o" <tytso@....edu>
To:     Matthew Wilcox <willy@...radead.org>
Cc:     "Darrick J. Wong" <djwong@...nel.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 Wed, Jul 20, 2022 at 03:11:21PM +0100, Matthew Wilcox wrote:
> Uhhh.  So what are the semantics of len?  That is, on SET, what does
> a filesystem do if userspace says "Here's 8 bytes" but the filesystem
> usually uses 16 bytes?  What does the same filesystem do if userspace
> offers it 32 bytes?  If the answer is "returns -EINVAL", how does
> userspace discover what size of volume ID is acceptable to a particular
> filesystem?
> 
> And then, on GET, does 'len' just mean "here's the length of the buffer,
> put however much will fit into it"?  Should filesystems update it to
> inform userspace how much was transferred?

What I'd suggest is that for GET, the length field when called should
be the length of the buffer, and if the length is too small, we should
return some error --- probably EINVAL or ENOSPC.  If the buffer size
length is larger than what is needed, having the file system update it
with the size of the UUID that was returned.

And this would be how the userspace can discover size of the UUID.  In
practice, though, the human user is going to be suppliyng the UUID,
which means the *human* is going to have to understand that "oh, this
is a VFAT file system, so I need to give 32-bit UUID formatted as
DEAD-BEAF" or "oh, this is a ntfs file system, so I need to enter into
the command line a UUID formatted as the text string
A24E62F14E62BDA3".  (The user might also end up having to ntfs or vfat
specific uuid changing tool; that's unclear at this point.)

As far as Jeremy's patch is concerned, I don't think we need to change
anything forthe SET ioctl, but for the GET util, it would be better in
the extremely unlikely case where the user pass in a length larger
than 16 bytes (say, 32), that we return the 16 byte UUID, and update
the length field to be 16 bytes.

I don't think it's strictly necessary, since in practice there is no
reason why a file system's volume identifier would ever be larger than
16 bytes --- the chances that we might need an extra 240 bytes to
specify a multiverse identifier seems.... unlikely.  :-)

				- Ted