From: Tycho Andersen <tycho.andersen-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
To: "Michael Kerrisk (man-pages)"
<mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Kees Cook <keescook-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>,
Linux API <linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Alexei Starovoitov <ast-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Will Drewry <wad-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>,
Oleg Nesterov <oleg-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org>,
Pavel Emelyanov <xemul-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>,
"Serge E. Hallyn"
<serge.hallyn-GeWIH/nMZzLQT0dZR+AlfA@public.gmane.org>,
Daniel Borkmann <daniel-FeC+5ew28dpmcu3hnIyYJQ@public.gmane.org>,
LKML <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Network Development
<netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [PATCH 5/6] seccomp: add a way to attach a filter via eBPF fd
Date: Tue, 8 Sep 2015 07:40:44 -0600 [thread overview]
Message-ID: <20150908134044.GV26679@smitten> (raw)
In-Reply-To: <55EA95FE.7000006-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Sat, Sep 05, 2015 at 09:13:02AM +0200, Michael Kerrisk (man-pages) wrote:
> On 09/04/2015 10:41 PM, Kees Cook wrote:
> > On Fri, Sep 4, 2015 at 9:04 AM, Tycho Andersen
> > <tycho.andersen-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org> wrote:
> >> This is the final bit needed to support seccomp filters created via the bpf
> >> syscall.
>
> Hmm. Thanks Kees, for CCinf linux-api@. That really should have been done at
> the outset.
Apologies, I'll cc the list on future versions.
> Tycho, where's the man-pages patch describing this new kernel-userspace
> API feature? :-)
Once we get the API finalized I'm happy to write it.
> >> One concern with this patch is exactly what the interface should look like
> >> for users, since seccomp()'s second argument is a pointer, we could ask
> >> people to pass a pointer to the fd, but implies we might write to it which
> >> seems impolite. Right now we cast the pointer (and force the user to cast
> >> it), which generates ugly warnings. I'm not sure what the right answer is
> >> here.
> >>
> >> Signed-off-by: Tycho Andersen <tycho.andersen-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
> >> CC: Kees Cook <keescook-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> >> CC: Will Drewry <wad-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> >> CC: Oleg Nesterov <oleg-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> >> CC: Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org>
> >> CC: Pavel Emelyanov <xemul-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
> >> CC: Serge E. Hallyn <serge.hallyn-GeWIH/nMZzLQT0dZR+AlfA@public.gmane.org>
> >> CC: Alexei Starovoitov <ast-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> >> CC: Daniel Borkmann <daniel-FeC+5ew28dpmcu3hnIyYJQ@public.gmane.org>
> >> ---
> >> include/linux/seccomp.h | 3 +-
> >> include/uapi/linux/seccomp.h | 1 +
> >> kernel/seccomp.c | 70 ++++++++++++++++++++++++++++++++++++--------
> >> 3 files changed, 61 insertions(+), 13 deletions(-)
> >>
> >> diff --git a/include/linux/seccomp.h b/include/linux/seccomp.h
> >> index d1a86ed..a725dd5 100644
> >> --- a/include/linux/seccomp.h
> >> +++ b/include/linux/seccomp.h
> >> @@ -3,7 +3,8 @@
> >>
> >> #include <uapi/linux/seccomp.h>
> >>
> >> -#define SECCOMP_FILTER_FLAG_MASK (SECCOMP_FILTER_FLAG_TSYNC)
> >> +#define SECCOMP_FILTER_FLAG_MASK (\
> >> + SECCOMP_FILTER_FLAG_TSYNC | SECCOMP_FILTER_FLAG_EBPF)
> >>
> >> #ifdef CONFIG_SECCOMP
> >>
> >> diff --git a/include/uapi/linux/seccomp.h b/include/uapi/linux/seccomp.h
> >> index 0f238a4..c29a423 100644
> >> --- a/include/uapi/linux/seccomp.h
> >> +++ b/include/uapi/linux/seccomp.h
> >> @@ -16,6 +16,7 @@
> >>
> >> /* Valid flags for SECCOMP_SET_MODE_FILTER */
> >> #define SECCOMP_FILTER_FLAG_TSYNC 1
> >> +#define SECCOMP_FILTER_FLAG_EBPF (1 << 1)
> >>
> >> /*
> >> * All BPF programs must return a 32-bit value.
> >> diff --git a/kernel/seccomp.c b/kernel/seccomp.c
> >> index a2c5b32..9c6bea6 100644
> >> --- a/kernel/seccomp.c
> >> +++ b/kernel/seccomp.c
> >> @@ -355,17 +355,6 @@ static struct seccomp_filter *seccomp_prepare_filter(struct sock_fprog *fprog)
> >>
> >> BUG_ON(INT_MAX / fprog->len < sizeof(struct sock_filter));
> >>
> >> - /*
> >> - * Installing a seccomp filter requires that the task has
> >> - * CAP_SYS_ADMIN in its namespace or be running with no_new_privs.
> >> - * This avoids scenarios where unprivileged tasks can affect the
> >> - * behavior of privileged children.
> >> - */
> >> - if (!task_no_new_privs(current) &&
> >> - security_capable_noaudit(current_cred(), current_user_ns(),
> >> - CAP_SYS_ADMIN) != 0)
> >> - return ERR_PTR(-EACCES);
> >> -
> >> /* Allocate a new seccomp_filter */
> >> sfilter = kzalloc(sizeof(*sfilter), GFP_KERNEL | __GFP_NOWARN);
> >> if (!sfilter)
> >> @@ -509,6 +498,48 @@ static void seccomp_send_sigsys(int syscall, int reason)
> >> info.si_syscall = syscall;
> >> force_sig_info(SIGSYS, &info, current);
> >> }
> >> +
> >> +#ifdef CONFIG_BPF_SYSCALL
> >> +static struct seccomp_filter *seccomp_prepare_ebpf(const char __user *filter)
> >> +{
> >> + /* XXX: this cast generates a warning. should we make people pass in
> >> + * &fd, or is there some nicer way of doing this?
> >> + */
> >> + u32 fd = (u32) filter;
> >
> > I think this is probably the right way to do it, modulo getting the
> > warning fixed. Let me invoke the great linux-api subscribers to get
> > some more opinions.
>
> Sigh. It's sad, but the using a cast does seem the simplest option.
> But, how about another idea...
>
> > tl;dr: adding SECCOMP_FILTER_FLAG_EBPF to the flags changes the
> > pointer argument into an fd argument. Is this sane, should it be a
> > pointer to an fd, or should it not be a flag at all, creating a new
> > seccomp command instead (SECCOMP_MODE_FILTER_EBPF)?
>
> What about
>
> seccomp(SECCOMP_MODE_FILTER_EBPF, flags, structp)
>
> Where structp is a pointer to something like
>
> struct seccomp_ebpf {
> int size; /* Size of this whole struct */
> int fd;
> }
>
> 'size' allows for future expansion of the struct (in case we want to
> expand it later), and placing 'fd' inside a struct avoids unpleasant
> implication that would be made by passing a pointer to an fd as the
> third argument.
I like this; although perhaps something like bpf() has, with the
unions inside the struct so that we don't have to declare another
struct if we add another seccomp command. Kees?
Tycho
> Cheers,
>
> Michael
>
>
> > -Kees
> >
> >> + struct seccomp_filter *ret;
> >> + struct bpf_prog *prog;
> >> +
> >> + prog = bpf_prog_get(fd);
> >> + if (IS_ERR(prog))
> >> + return (struct seccomp_filter *) prog;
> >> +
> >> + if (prog->type != BPF_PROG_TYPE_SECCOMP) {
> >> + bpf_prog_put(prog);
> >> + return ERR_PTR(-EINVAL);
> >> + }
> >> +
> >> + ret = kzalloc(sizeof(*ret), GFP_KERNEL | __GFP_NOWARN);
> >> + if (!ret) {
> >> + bpf_prog_put(prog);
> >> + return ERR_PTR(-ENOMEM);
> >> + }
> >> +
> >> + ret->prog = prog;
> >> + atomic_set(&ret->usage, 1);
> >> +
> >> + /* Intentionally don't bpf_prog_put() here, because the underlying prog
> >> + * is refcounted too and we're holding a reference from the struct
> >> + * seccomp_filter object.
> >> + */
> >> +
> >> + return ret;
> >> +}
> >> +#else
> >> +static struct seccomp_filter *seccomp_prepare_ebpf(const char __user *filter)
> >> +{
> >> + return ERR_PTR(-EINVAL);
> >> +}
> >> +#endif
> >> #endif /* CONFIG_SECCOMP_FILTER */
> >>
> >> /*
> >> @@ -775,8 +806,23 @@ static long seccomp_set_mode_filter(unsigned int flags,
> >> if (flags & ~SECCOMP_FILTER_FLAG_MASK)
> >> return -EINVAL;
> >>
> >> + /*
> >> + * Installing a seccomp filter requires that the task has
> >> + * CAP_SYS_ADMIN in its namespace or be running with no_new_privs.
> >> + * This avoids scenarios where unprivileged tasks can affect the
> >> + * behavior of privileged children.
> >> + */
> >> + if (!task_no_new_privs(current) &&
> >> + security_capable_noaudit(current_cred(), current_user_ns(),
> >> + CAP_SYS_ADMIN) != 0)
> >> + return -EACCES;
> >> +
> >> /* Prepare the new filter before holding any locks. */
> >> - prepared = seccomp_prepare_user_filter(filter);
> >> + if (flags & SECCOMP_FILTER_FLAG_EBPF)
> >> + prepared = seccomp_prepare_ebpf(filter);
> >> + else
> >> + prepared = seccomp_prepare_user_filter(filter);
> >> +
> >> if (IS_ERR(prepared))
> >> return PTR_ERR(prepared);
> >>
> >> --
> >> 2.1.4
> >>
> >
> >
> >
>
>
> --
> Michael Kerrisk
> Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
> Linux/UNIX System Programming Training: http://man7.org/training/
WARNING: multiple messages have this Message-ID (diff)
From: Tycho Andersen <tycho.andersen@canonical.com>
To: "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
Cc: Kees Cook <keescook@chromium.org>,
Linux API <linux-api@vger.kernel.org>,
Alexei Starovoitov <ast@kernel.org>,
Will Drewry <wad@chromium.org>, Oleg Nesterov <oleg@redhat.com>,
Andy Lutomirski <luto@amacapital.net>,
Pavel Emelyanov <xemul@parallels.com>,
"Serge E. Hallyn" <serge.hallyn@ubuntu.com>,
Daniel Borkmann <daniel@iogearbox.net>,
LKML <linux-kernel@vger.kernel.org>,
Network Development <netdev@vger.kernel.org>
Subject: Re: [PATCH 5/6] seccomp: add a way to attach a filter via eBPF fd
Date: Tue, 8 Sep 2015 07:40:44 -0600 [thread overview]
Message-ID: <20150908134044.GV26679@smitten> (raw)
In-Reply-To: <55EA95FE.7000006@gmail.com>
On Sat, Sep 05, 2015 at 09:13:02AM +0200, Michael Kerrisk (man-pages) wrote:
> On 09/04/2015 10:41 PM, Kees Cook wrote:
> > On Fri, Sep 4, 2015 at 9:04 AM, Tycho Andersen
> > <tycho.andersen@canonical.com> wrote:
> >> This is the final bit needed to support seccomp filters created via the bpf
> >> syscall.
>
> Hmm. Thanks Kees, for CCinf linux-api@. That really should have been done at
> the outset.
Apologies, I'll cc the list on future versions.
> Tycho, where's the man-pages patch describing this new kernel-userspace
> API feature? :-)
Once we get the API finalized I'm happy to write it.
> >> One concern with this patch is exactly what the interface should look like
> >> for users, since seccomp()'s second argument is a pointer, we could ask
> >> people to pass a pointer to the fd, but implies we might write to it which
> >> seems impolite. Right now we cast the pointer (and force the user to cast
> >> it), which generates ugly warnings. I'm not sure what the right answer is
> >> here.
> >>
> >> Signed-off-by: Tycho Andersen <tycho.andersen@canonical.com>
> >> CC: Kees Cook <keescook@chromium.org>
> >> CC: Will Drewry <wad@chromium.org>
> >> CC: Oleg Nesterov <oleg@redhat.com>
> >> CC: Andy Lutomirski <luto@amacapital.net>
> >> CC: Pavel Emelyanov <xemul@parallels.com>
> >> CC: Serge E. Hallyn <serge.hallyn@ubuntu.com>
> >> CC: Alexei Starovoitov <ast@kernel.org>
> >> CC: Daniel Borkmann <daniel@iogearbox.net>
> >> ---
> >> include/linux/seccomp.h | 3 +-
> >> include/uapi/linux/seccomp.h | 1 +
> >> kernel/seccomp.c | 70 ++++++++++++++++++++++++++++++++++++--------
> >> 3 files changed, 61 insertions(+), 13 deletions(-)
> >>
> >> diff --git a/include/linux/seccomp.h b/include/linux/seccomp.h
> >> index d1a86ed..a725dd5 100644
> >> --- a/include/linux/seccomp.h
> >> +++ b/include/linux/seccomp.h
> >> @@ -3,7 +3,8 @@
> >>
> >> #include <uapi/linux/seccomp.h>
> >>
> >> -#define SECCOMP_FILTER_FLAG_MASK (SECCOMP_FILTER_FLAG_TSYNC)
> >> +#define SECCOMP_FILTER_FLAG_MASK (\
> >> + SECCOMP_FILTER_FLAG_TSYNC | SECCOMP_FILTER_FLAG_EBPF)
> >>
> >> #ifdef CONFIG_SECCOMP
> >>
> >> diff --git a/include/uapi/linux/seccomp.h b/include/uapi/linux/seccomp.h
> >> index 0f238a4..c29a423 100644
> >> --- a/include/uapi/linux/seccomp.h
> >> +++ b/include/uapi/linux/seccomp.h
> >> @@ -16,6 +16,7 @@
> >>
> >> /* Valid flags for SECCOMP_SET_MODE_FILTER */
> >> #define SECCOMP_FILTER_FLAG_TSYNC 1
> >> +#define SECCOMP_FILTER_FLAG_EBPF (1 << 1)
> >>
> >> /*
> >> * All BPF programs must return a 32-bit value.
> >> diff --git a/kernel/seccomp.c b/kernel/seccomp.c
> >> index a2c5b32..9c6bea6 100644
> >> --- a/kernel/seccomp.c
> >> +++ b/kernel/seccomp.c
> >> @@ -355,17 +355,6 @@ static struct seccomp_filter *seccomp_prepare_filter(struct sock_fprog *fprog)
> >>
> >> BUG_ON(INT_MAX / fprog->len < sizeof(struct sock_filter));
> >>
> >> - /*
> >> - * Installing a seccomp filter requires that the task has
> >> - * CAP_SYS_ADMIN in its namespace or be running with no_new_privs.
> >> - * This avoids scenarios where unprivileged tasks can affect the
> >> - * behavior of privileged children.
> >> - */
> >> - if (!task_no_new_privs(current) &&
> >> - security_capable_noaudit(current_cred(), current_user_ns(),
> >> - CAP_SYS_ADMIN) != 0)
> >> - return ERR_PTR(-EACCES);
> >> -
> >> /* Allocate a new seccomp_filter */
> >> sfilter = kzalloc(sizeof(*sfilter), GFP_KERNEL | __GFP_NOWARN);
> >> if (!sfilter)
> >> @@ -509,6 +498,48 @@ static void seccomp_send_sigsys(int syscall, int reason)
> >> info.si_syscall = syscall;
> >> force_sig_info(SIGSYS, &info, current);
> >> }
> >> +
> >> +#ifdef CONFIG_BPF_SYSCALL
> >> +static struct seccomp_filter *seccomp_prepare_ebpf(const char __user *filter)
> >> +{
> >> + /* XXX: this cast generates a warning. should we make people pass in
> >> + * &fd, or is there some nicer way of doing this?
> >> + */
> >> + u32 fd = (u32) filter;
> >
> > I think this is probably the right way to do it, modulo getting the
> > warning fixed. Let me invoke the great linux-api subscribers to get
> > some more opinions.
>
> Sigh. It's sad, but the using a cast does seem the simplest option.
> But, how about another idea...
>
> > tl;dr: adding SECCOMP_FILTER_FLAG_EBPF to the flags changes the
> > pointer argument into an fd argument. Is this sane, should it be a
> > pointer to an fd, or should it not be a flag at all, creating a new
> > seccomp command instead (SECCOMP_MODE_FILTER_EBPF)?
>
> What about
>
> seccomp(SECCOMP_MODE_FILTER_EBPF, flags, structp)
>
> Where structp is a pointer to something like
>
> struct seccomp_ebpf {
> int size; /* Size of this whole struct */
> int fd;
> }
>
> 'size' allows for future expansion of the struct (in case we want to
> expand it later), and placing 'fd' inside a struct avoids unpleasant
> implication that would be made by passing a pointer to an fd as the
> third argument.
I like this; although perhaps something like bpf() has, with the
unions inside the struct so that we don't have to declare another
struct if we add another seccomp command. Kees?
Tycho
> Cheers,
>
> Michael
>
>
> > -Kees
> >
> >> + struct seccomp_filter *ret;
> >> + struct bpf_prog *prog;
> >> +
> >> + prog = bpf_prog_get(fd);
> >> + if (IS_ERR(prog))
> >> + return (struct seccomp_filter *) prog;
> >> +
> >> + if (prog->type != BPF_PROG_TYPE_SECCOMP) {
> >> + bpf_prog_put(prog);
> >> + return ERR_PTR(-EINVAL);
> >> + }
> >> +
> >> + ret = kzalloc(sizeof(*ret), GFP_KERNEL | __GFP_NOWARN);
> >> + if (!ret) {
> >> + bpf_prog_put(prog);
> >> + return ERR_PTR(-ENOMEM);
> >> + }
> >> +
> >> + ret->prog = prog;
> >> + atomic_set(&ret->usage, 1);
> >> +
> >> + /* Intentionally don't bpf_prog_put() here, because the underlying prog
> >> + * is refcounted too and we're holding a reference from the struct
> >> + * seccomp_filter object.
> >> + */
> >> +
> >> + return ret;
> >> +}
> >> +#else
> >> +static struct seccomp_filter *seccomp_prepare_ebpf(const char __user *filter)
> >> +{
> >> + return ERR_PTR(-EINVAL);
> >> +}
> >> +#endif
> >> #endif /* CONFIG_SECCOMP_FILTER */
> >>
> >> /*
> >> @@ -775,8 +806,23 @@ static long seccomp_set_mode_filter(unsigned int flags,
> >> if (flags & ~SECCOMP_FILTER_FLAG_MASK)
> >> return -EINVAL;
> >>
> >> + /*
> >> + * Installing a seccomp filter requires that the task has
> >> + * CAP_SYS_ADMIN in its namespace or be running with no_new_privs.
> >> + * This avoids scenarios where unprivileged tasks can affect the
> >> + * behavior of privileged children.
> >> + */
> >> + if (!task_no_new_privs(current) &&
> >> + security_capable_noaudit(current_cred(), current_user_ns(),
> >> + CAP_SYS_ADMIN) != 0)
> >> + return -EACCES;
> >> +
> >> /* Prepare the new filter before holding any locks. */
> >> - prepared = seccomp_prepare_user_filter(filter);
> >> + if (flags & SECCOMP_FILTER_FLAG_EBPF)
> >> + prepared = seccomp_prepare_ebpf(filter);
> >> + else
> >> + prepared = seccomp_prepare_user_filter(filter);
> >> +
> >> if (IS_ERR(prepared))
> >> return PTR_ERR(prepared);
> >>
> >> --
> >> 2.1.4
> >>
> >
> >
> >
>
>
> --
> Michael Kerrisk
> Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
> Linux/UNIX System Programming Training: http://man7.org/training/
next prev parent reply other threads:[~2015-09-08 13:40 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-04 16:04 c/r of seccomp filters via underlying eBPF Tycho Andersen
2015-09-04 16:04 ` [PATCH 1/6] ebpf: add a seccomp program type Tycho Andersen
2015-09-04 20:17 ` Alexei Starovoitov
2015-09-04 21:09 ` Tycho Andersen
2015-09-04 20:34 ` Kees Cook
2015-09-04 21:06 ` Tycho Andersen
2015-09-04 21:08 ` Kees Cook
2015-09-09 15:50 ` Tycho Andersen
2015-09-09 16:07 ` Alexei Starovoitov
2015-09-09 16:09 ` Daniel Borkmann
2015-09-09 16:37 ` Kees Cook
2015-09-09 16:52 ` Alexei Starovoitov
2015-09-09 17:27 ` Kees Cook
2015-09-09 17:31 ` Tycho Andersen
2015-09-09 16:07 ` Daniel Borkmann
2015-09-04 21:50 ` Andy Lutomirski
2015-09-09 16:13 ` Daniel Borkmann
2015-09-04 16:04 ` [PATCH 2/6] seccomp: make underlying bpf ref counted as well Tycho Andersen
2015-09-04 21:53 ` Andy Lutomirski
2015-09-04 16:04 ` [PATCH 3/6] ebpf: add a way to dump an eBPF program Tycho Andersen
2015-09-04 20:17 ` Kees Cook
2015-09-04 20:45 ` Tycho Andersen
2015-09-04 20:50 ` Kees Cook
2015-09-04 20:58 ` Alexei Starovoitov
2015-09-04 21:00 ` Tycho Andersen
2015-09-04 21:48 ` Andy Lutomirski
2015-09-04 22:28 ` Tycho Andersen
2015-09-04 23:08 ` Andy Lutomirski
2015-09-05 0:27 ` Tycho Andersen
2015-09-09 22:34 ` Tycho Andersen
2015-09-09 23:44 ` Andy Lutomirski
2015-09-10 0:13 ` Tycho Andersen
2015-09-10 0:44 ` Andy Lutomirski
2015-09-10 0:58 ` Tycho Andersen
2015-09-04 23:27 ` Kees Cook
2015-09-05 0:08 ` Andy Lutomirski
2015-09-04 20:27 ` Alexei Starovoitov
2015-09-04 20:42 ` Tycho Andersen
2015-09-04 16:04 ` [PATCH 4/6] seccomp: add a way to access filters via bpf fds Tycho Andersen
2015-09-04 20:26 ` Kees Cook
2015-09-04 20:29 ` Alexei Starovoitov
2015-09-04 20:58 ` Tycho Andersen
2015-09-04 16:04 ` [PATCH 5/6] seccomp: add a way to attach a filter via eBPF fd Tycho Andersen
2015-09-04 20:40 ` Alexei Starovoitov
[not found] ` <1441382664-17437-6-git-send-email-tycho.andersen-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
2015-09-04 20:41 ` Kees Cook
2015-09-04 20:41 ` Kees Cook
[not found] ` <CAGXu5jKke44txdYqEgPRrkn8SyWGjJuHxT2qMdq2ztp_16mQyw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-09-05 7:13 ` Michael Kerrisk (man-pages)
2015-09-05 7:13 ` Michael Kerrisk (man-pages)
[not found] ` <55EA95FE.7000006-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2015-09-08 13:40 ` Tycho Andersen [this message]
2015-09-08 13:40 ` Tycho Andersen
2015-09-09 0:07 ` Kees Cook
2015-09-09 0:07 ` Kees Cook
[not found] ` <CAGXu5jKS0yX92XXhL6ZkqMrxkqFpPyyBd7wbsvEEx4rqZ0VG6g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-09-09 14:47 ` Tycho Andersen
2015-09-09 14:47 ` Tycho Andersen
2015-09-09 15:14 ` Alexei Starovoitov
2015-09-09 15:14 ` Alexei Starovoitov
[not found] ` <20150909151402.GA3429-2RGepAHry04KGsCuBW9QBvb0xQGhdpdCAL8bYrjMMd8@public.gmane.org>
2015-09-09 15:55 ` Tycho Andersen
2015-09-09 15:55 ` Tycho Andersen
2015-09-04 16:04 ` [PATCH 6/6] ebpf: allow BPF_REG_X in src_reg conditional jumps Tycho Andersen
2015-09-04 21:06 ` Alexei Starovoitov
2015-09-04 22:43 ` Tycho Andersen
2015-09-05 4:12 ` Alexei Starovoitov
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=20150908134044.GV26679@smitten \
--to=tycho.andersen-z7wlfzj8ewms+fvcfc7uqw@public.gmane.org \
--cc=ast-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=daniel-FeC+5ew28dpmcu3hnIyYJQ@public.gmane.org \
--cc=keescook-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org \
--cc=linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org \
--cc=mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=oleg-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=serge.hallyn-GeWIH/nMZzLQT0dZR+AlfA@public.gmane.org \
--cc=wad-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org \
--cc=xemul-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.