[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200717162526.GA17072@lst.de>
Date: Fri, 17 Jul 2020 18:25:26 +0200
From: Christoph Hellwig <hch@....de>
To: Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc: Christoph Hellwig <hch@....de>,
Stanislav Fomichev <sdf@...gle.com>,
Alexei Starovoitov <ast@...nel.org>,
"David S. Miller" <davem@...emloft.net>,
Network Development <netdev@...r.kernel.org>,
bpf <bpf@...r.kernel.org>
Subject: Re: how is the bpfilter sockopt processing supposed to work
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@....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?
Powered by blists - more mailing lists