netdev - Re: [PATCH net-next v4 01/12] inet: homa: define user-visible API for Homa

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]

Message-Id: <f1a91e78-8187-458e-942c-880b8792aa6d@app.fastmail.com>
Date: Fri, 20 Dec 2024 22:12:23 +0100
From: "Arnd Bergmann" <arnd@...db.de>
To: "Jakub Kicinski" <kuba@...nel.org>,
 "John Ousterhout" <ouster@...stanford.edu>
Cc: Netdev <netdev@...r.kernel.org>, "Paolo Abeni" <pabeni@...hat.com>,
 "Eric Dumazet" <edumazet@...gle.com>, "Simon Horman" <horms@...nel.org>
Subject: Re: [PATCH net-next v4 01/12] inet: homa: define user-visible API for Homa

On Fri, Dec 20, 2024, at 20:31, Jakub Kicinski wrote:
> On Fri, 20 Dec 2024 09:59:53 -0800 John Ousterhout wrote:
>> > > I see that "void *" is used in the declaration for struct msghdr
>> > > (along with some other pointer types as well) and struct msghdr is
>> > > part of several uAPI interfaces, no?  
>> >
>> > Off the top off my head this use is a source of major pain, grep around
>> > for compat_msghdr.  
>> 
>> How should I go about confirming that this __aligned_u64 is indeed the
>> expected convention (sounds like you aren't certain)?
>
> Let me add Arnd Bergmann to the CC list, he will correct me if 
> I'm wrong. Otherwise you can trust my intuition :)

You are right that for the purposes of the user API, structures
should use __u64 or __aligned_u64 in place of pointers, there are
some more details on this in Documentation/driver-api/ioctl.rst.

What worries me more in this particular case is the way that
this pointer is passed through setsockopt(), which really doesn't
take any pointers in other protocols.

I have not fully understood what is behind the pointer, but
it looks like this gets stored in the kernel in a per-socket
structure that is annotated as a kernel pointer, not a user
pointer, which may cause additional problems.

I don't know if the same pointer ever points to a kernel
structure, but if it does, that needs to be fixed first.

Assuming this is actually meant as a persistent __user
pointer, I'm still unsure what this means if the socket is
available to more than one process, e.g. through a fork()
or explicit file descriptor passing, or if the original
process dies while there is still a transfer in progress.
I realize that there is a lot of information already out
there that I haven't all read, so this is probably explained
somewhere, but it would be nice to point to that documentation
somewhere near the code to clarify the corner cases.

That probably also explains what type of memory the
__user buffer can point to, but I would like to make
sure that this has well-defined behavior e.g. if that
buffer is an mmap()ed file on NFS that was itself
mounted over a homa socket. Is there any guarantee that
this is either prohibited or is free of deadlocks and
recursion?

      Arnd