[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20161220045155.GC86803@ast-mbp.thefacebook.com>
Date: Mon, 19 Dec 2016 20:51:56 -0800
From: Alexei Starovoitov <alexei.starovoitov@...il.com>
To: Andy Lutomirski <luto@...capital.net>
Cc: David Miller <davem@...emloft.net>,
Andrew Lutomirski <luto@...nel.org>,
Daniel Mack <daniel@...que.org>,
Mickaël Salaün <mic@...ikod.net>,
Kees Cook <keescook@...omium.org>, Jann Horn <jann@...jh.net>,
Tejun Heo <tj@...nel.org>, David Ahern <dsahern@...il.com>,
Thomas Graf <tgraf@...g.ch>,
Michael Kerrisk <mtk.manpages@...il.com>,
Peter Zijlstra <peterz@...radead.org>,
Linux API <linux-api@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Network Development <netdev@...r.kernel.org>
Subject: Re: Potential issues (security and otherwise) with the current
cgroup-bpf API
On Mon, Dec 19, 2016 at 05:40:53PM -0800, Andy Lutomirski wrote:
>
> By the way, even if Alexei is right, the BPF_PROG_DETACH API doesn't
> even take a reference to a BPF program as an argument. What is it
> supposed to do if this mechanism ever gets extended?
we just add another field to that anonymous union just like
we did for other commands and everything is backwards compatible.
It's the basics of bpf syscall that we've been relying on for some
time now and it worked just fine.
Powered by blists - more mailing lists