linux-kernel - Re: [PATCH v3] fs: introduce getfsxattrat and setfsxattrat syscalls

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 for Android: free password hash cracker in your pocket

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

Message-Id: <3c860dc0-ba8d-4324-b286-c160b7d8d2c4@app.fastmail.com>
Date: Tue, 25 Feb 2025 11:40:51 +0100
From: "Arnd Bergmann" <arnd@...db.de>
To: "Christian Brauner" <brauner@...nel.org>
Cc: "Amir Goldstein" <amir73il@...il.com>,
 "Andrey Albershteyn" <aalbersh@...hat.com>,
 "Darrick J. Wong" <djwong@...nel.org>,
 "Richard Henderson" <richard.henderson@...aro.org>,
 "Matt Turner" <mattst88@...il.com>,
 "Russell King" <linux@...linux.org.uk>,
 "Catalin Marinas" <catalin.marinas@....com>,
 "Will Deacon" <will@...nel.org>,
 "Geert Uytterhoeven" <geert@...ux-m68k.org>,
 "Michal Simek" <monstr@...str.eu>,
 "Thomas Bogendoerfer" <tsbogend@...ha.franken.de>,
 "James E . J . Bottomley" <James.Bottomley@...senpartnership.com>,
 "Helge Deller" <deller@....de>,
 "Madhavan Srinivasan" <maddy@...ux.ibm.com>,
 "Michael Ellerman" <mpe@...erman.id.au>,
 "Nicholas Piggin" <npiggin@...il.com>,
 "Christophe Leroy" <christophe.leroy@...roup.eu>,
 "Naveen N Rao" <naveen@...nel.org>, "Heiko Carstens" <hca@...ux.ibm.com>,
 "Vasily Gorbik" <gor@...ux.ibm.com>,
 "Alexander Gordeev" <agordeev@...ux.ibm.com>,
 "Christian Borntraeger" <borntraeger@...ux.ibm.com>,
 "Sven Schnelle" <svens@...ux.ibm.com>,
 "Yoshinori Sato" <ysato@...rs.sourceforge.jp>,
 "Rich Felker" <dalias@...c.org>,
 "John Paul Adrian Glaubitz" <glaubitz@...sik.fu-berlin.de>,
 "David S . Miller" <davem@...emloft.net>,
 "Andreas Larsson" <andreas@...sler.com>,
 "Andy Lutomirski" <luto@...nel.org>,
 "Thomas Gleixner" <tglx@...utronix.de>, "Ingo Molnar" <mingo@...hat.com>,
 "Borislav Petkov" <bp@...en8.de>,
 "Dave Hansen" <dave.hansen@...ux.intel.com>, x86@...nel.org,
 "H. Peter Anvin" <hpa@...or.com>, "Chris Zankel" <chris@...kel.net>,
 "Max Filippov" <jcmvbkbc@...il.com>,
 "Alexander Viro" <viro@...iv.linux.org.uk>, "Jan Kara" <jack@...e.cz>,
 Mickaël Salaün <mic@...ikod.net>,
 Günther Noack <gnoack@...gle.com>,
 linux-alpha@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-arm-kernel@...ts.infradead.org, linux-m68k@...ts.linux-m68k.org,
 linux-mips@...r.kernel.org, linux-parisc@...r.kernel.org,
 linuxppc-dev@...ts.ozlabs.org, linux-s390@...r.kernel.org,
 linux-sh@...r.kernel.org, sparclinux@...r.kernel.org,
 linux-fsdevel@...r.kernel.org, linux-security-module@...r.kernel.org,
 linux-api@...r.kernel.org, Linux-Arch <linux-arch@...r.kernel.org>,
 linux-xfs@...r.kernel.org, Pali Rohár <pali@...nel.org>,
 "Theodore Ts'o" <tytso@....edu>
Subject: Re: [PATCH v3] fs: introduce getfsxattrat and setfsxattrat syscalls

On Tue, Feb 25, 2025, at 11:22, Christian Brauner wrote:
> On Tue, Feb 25, 2025 at 09:02:04AM +0100, Arnd Bergmann wrote:
>> On Mon, Feb 24, 2025, at 12:32, Christian Brauner wrote:
>> 
>> The ioctl interface relies on the existing behavior, see
>> 0a6eab8bd4e0 ("vfs: support FS_XFLAG_COWEXTSIZE and get/set of
>> CoW extent size hint") for how it was previously extended
>> with an optional flag/word. I think that is fine for the syscall
>> as well, but should be properly documented since it is different
>> from how most syscalls work.
>
> If we're doing a new system call I see no reason to limit us to a
> pre-existing structure or structure layout.

Obviously we could create a new structure, but I also see no
reason to do so. The existing ioctl interface was added in
in 2002 as part of linux-2.5.35 with 16 bytes of padding, half
of which have been used so far.

If this structure works for another 23 years before we run out
of spare bytes, I think that's good enough. Building in an
incompatible way to handle potential future contents would
just make it harder to use for any userspace that wants to
use the new syscalls but still needs a fallback to the
ioctl version.

     Arnd