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@xxxxxx> 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?
