From: Christoph Hellwig <hch@lst.de>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: Christoph Hellwig <hch@lst.de>,
Stanislav Fomichev <sdf@google.com>,
Alexei Starovoitov <ast@kernel.org>,
"David S. Miller" <davem@davemloft.net>,
Network Development <netdev@vger.kernel.org>,
bpf <bpf@vger.kernel.org>
Subject: Re: how is the bpfilter sockopt processing supposed to work
Date: Fri, 17 Jul 2020 18:25:26 +0200 [thread overview]
Message-ID: <20200717162526.GA17072@lst.de> (raw)
In-Reply-To: <CAADnVQ+rD+7fAsLZT4pG7AN4iO7-dQ+3adw0tBhrf8TGbtLjtA@mail.gmail.com>
On Fri, Jul 17, 2020 at 09:13:07AM -0700, Alexei Starovoitov wrote:
> On Thu, Jul 16, 2020 at 10:52 PM Christoph Hellwig <hch@lst.de> wrote:
> >
> > Hi Alexei,
> >
> > I've just been auditing the sockopt code, and bpfilter looks really
> > odd. Both getsockopts and setsockopt eventually end up
> > in__bpfilter_process_sockopt, which then passes record to the
> > userspace helper containing the address of the optval buffer.
> > Which depending on bpf-cgroup might be in user or kernel space.
> > But even if it is in userspace it would be in a different process
> > than the bpfiler helper. What makes all this work?
>
> Hmm. Good point. bpfilter assumes user addresses. It will break
> if bpf cgroup sockopt messes with it.
> We had a different issue with bpf-cgroup-sockopt and iptables in the past.
> Probably the easiest way forward is to special case this particular one.
> With your new series is there a way to tell in bpfilter_ip_get_sockopt()
> whether addr is kernel or user? And if it's the kernel just return with error.
Yes, I can send a fix. But how do even the user space addressed work?
If some random process calls getsockopt or setsockopt, how does the
bpfilter user mode helper attach to its address space?
next prev parent reply other threads:[~2020-07-17 16:25 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-17 5:52 how is the bpfilter sockopt processing supposed to work Christoph Hellwig
2020-07-17 16:13 ` Alexei Starovoitov
2020-07-17 16:25 ` Christoph Hellwig [this message]
2020-07-17 17:28 ` Alexei Starovoitov
2020-07-20 8:25 ` David Laight
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200717162526.GA17072@lst.de \
--to=hch@lst.de \
--cc=alexei.starovoitov@gmail.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
--cc=sdf@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).