netdev - Re: [PATCH net v2 2/3] net: prevent rewrite of msg_name in sock

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: <CADKFtnR5WANzLqA=WE_2Stii8aDPGy7Hi2tUReF1BtWe5FqOMw@mail.gmail.com>
Date: Mon, 18 Sep 2023 13:48:52 -0700
From: Jordan Rife <jrife@...gle.com>
To: Willem de Bruijn <willemdebruijn.kernel@...il.com>
Cc: davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org, 
	pabeni@...hat.com, netdev@...r.kernel.org, dborkman@...nel.org
Subject: Re: [PATCH net v2 2/3] net: prevent rewrite of msg_name in sock_sendmsg()

Just a heads up, there are also kernel_recvmsg/sock_recvmsg functions
that mirror the kernel_sendmsg/sock_sendmsg. If we are are doing this

> 1) Rename the current kernel_sendmsg() function to
> kernel_sendmsg_kvec() and name  our new function kernel_sendmsg(). To
> me this makes some sense, considering the new function is the more
> generic of the two, and the existing kernel_sendmsg() specifically
> accepts "struct kvec".

it creates an asymmetry between *sendmsg and *recvmsg function names.
If we wanted these to be similar then it means a rename to these
functions (e.g. kern_recvmsg becomes kern_recvmsg_kvec, rename
sock_recvmsg to kern_recvmsg).

-Jordan

On Mon, Sep 18, 2023 at 11:02 AM Jordan Rife <jrife@...gle.com> wrote:
>
> Sounds like a plan.
>
> On Mon, Sep 18, 2023 at 10:55 AM Willem de Bruijn
> <willemdebruijn.kernel@...il.com> wrote:
> >
> > On Mon, Sep 18, 2023 at 1:52 PM Jordan Rife <jrife@...gle.com> wrote:
> > >
> > > > You used this short-hand to avoid having to update all callers to sock_sendmsg to __kernel_sendmsg?
> > >
> > > Sorry about that, I misunderstood the intent. I'm fine with
> > > introducing a new function, doing the address copy there, and
> > > replacing all calls to sock_sendmsg with this wrapper. One thought on
> > > the naming though,
> > >
> > > To me the "__" prefix seems out of place for a function meant as a
> > > public interface. Some possible alternatives:
> > >
> > > 1) Rename the current kernel_sendmsg() function to
> > > kernel_sendmsg_kvec() and name  our new function kernel_sendmsg(). To
> > > me this makes some sense, considering the new function is the more
> > > generic of the two, and the existing kernel_sendmsg() specifically
> > > accepts "struct kvec".
> > > 2) Same as #1, but drop the old kernel_sendmsg() function instead of
> > > renaming it. Adapt all calls to the old kernel_sendmsg() to fit the
> > > new kernel_sendmsg() (this amounts to adding a
> > > iov_iter_kvec(&msg->msg_iter, ITER_SOURCE, vec, num, size); call in
> > > each spot before kernel_sendmsg() is called.
> >
> > Thanks. Fair points.
> >
> > Of the two proposals, I think the first is preferable, as it avoids
> > some non-trivial open coding in multiple callers.