Re: [PATCH 1/2] vmalloc: New flag for flush before releasing pages

On Tue, Dec 4, 2018 at 12:02 PM Edgecombe, Rick P wrote: > > On Tue, 2018-12-04 at 16:03 +, Will Deacon wrote: > > On Mon, Dec 03, 2018 at 05:43:11PM -0800, Nadav Amit wrote: > > > > On Nov 27, 2018, at 4:07 PM, Rick Edgecombe > > > > wrote: > > > > > > > > Since vfree will lazily flush the

Re: [PATCH net-next v6 07/23] zinc: ChaCha20 ARM and ARM64 implementations

> On Sep 27, 2018, at 8:19 AM, Jason A. Donenfeld wrote: > > Hey again Thomas, > >> On Thu, Sep 27, 2018 at 3:26 PM Jason A. Donenfeld wrote: >> >> Hi Thomas, >> >> I'm trying to optimize this for crypto performance while still taking >> into account preemption concerns. I'm having a bit

Re: [PATCH net-next v3 02/17] zinc: introduce minimal cryptography library

On Tue, Sep 11, 2018 at 4:57 PM David Miller wrote: > > From: Andrew Lunn > Date: Wed, 12 Sep 2018 01:30:15 +0200 > > > Just as an FYI: > > > > 1) I don't think anybody in netdev has taken a serious look at the > > network code yet. There is little point until the controversial part > > of the

Re: [PATCH v2 net-next 0/2] tcp: mmap: rework zerocopy receive

At the risk of further muddying the waters, there's another minor tweak that could improve performance on certain workloads. Currently you mmap() a range for a given socket and then getsockopt() to receive. If you made it so you could mmap() something once for any number of sockets (by mmapping

Re: [PATCH net-next 1/2] tcp: add TCP_ZEROCOPY_RECEIVE support for zerocopy receive

Y_RECEIVE, ...) implements >> >> the transfert of pages from skbs to one VMA. >> >> This operation only uses down_read(>mm->mmap_sem) after >> >> holding TCP lock, thus solving the lockdep issue. >> >> >> >> This new impl

Re: [PATCH net-next 0/4] mm,tcp: provide mmap_hook to solve lockdep issue

On Mon, Apr 23, 2018 at 2:38 PM, Eric Dumazet <eric.duma...@gmail.com> wrote: > Hi Andy > > On 04/23/2018 02:14 PM, Andy Lutomirski wrote: >> I would suggest that you rework the interface a bit. First a user would >> call mmap() on a TCP socket, which would create a

Re: [PATCH net-next 0/4] mm,tcp: provide mmap_hook to solve lockdep issue

On 04/20/2018 08:55 AM, Eric Dumazet wrote: This patch series provide a new mmap_hook to fs willing to grab a mutex before mm->mmap_sem is taken, to ensure lockdep sanity. This hook allows us to shorten tcp_mmap() execution time (while mmap_sem is held), and improve multi-threading scalability.

Re: [PATCH bpf-next v8 05/11] seccomp,landlock: Enforce Landlock programs per process hierarchy

On Sun, Apr 8, 2018 at 6:13 AM, Mickaël Salaün <m...@digikod.net> wrote: > > On 02/27/2018 10:48 PM, Mickaël Salaün wrote: >> >> On 27/02/2018 17:39, Andy Lutomirski wrote: >>> On Tue, Feb 27, 2018 at 5:32 AM, Alexei Starovoitov >>> <alexei.starovoi..

Re: [PATCH net-next] modules: allow modprobe load regular elf binaries

On Thu, Mar 22, 2018 at 8:54 PM, Luis R. Rodriguez wrote: > If we can ensure that these usermode modules don't take *any time at all* on > their init *from the start*, it would be wonderful and we'd end up avoiding > some really odd corner case issues later. > I don't see why

Re: [RFC PATCH 0/3] kernel: add support for 256-bit IO access

On Thu, Mar 22, 2018 at 5:40 PM, Alexei Starovoitov wrote: > On Thu, Mar 22, 2018 at 10:33:43AM +0100, Ingo Molnar wrote: >> >> - I think the BPF JIT, whose byte code machine languge is used by an >>increasing number of kernel subsystems, could benefit from

Re: [RFC PATCH 0/3] kernel: add support for 256-bit IO access

On Wed, Mar 21, 2018 at 6:32 AM, Ingo Molnar wrote: > > * Linus Torvalds wrote: > >> And even if you ignore that "maintenance problems down the line" issue >> ("we can fix them when they happen") I don't want to see games like >> this, because I'm

Re: [RFC PATCH 0/3] kernel: add support for 256-bit IO access

On Tue, Mar 20, 2018 at 3:10 PM, David Laight <david.lai...@aculab.com> wrote: > From: Andy Lutomirski >> Sent: 20 March 2018 14:57 > ... >> I'd rather see us finally finish the work that Rik started to rework >> this differently. I'd like k

Re: [RFC PATCH 0/3] kernel: add support for 256-bit IO access

On Tue, Mar 20, 2018 at 8:26 AM, Ingo Molnar wrote: > > * Thomas Gleixner wrote: > >> > Useful also for code that needs AVX-like registers to do things like CRCs. >> >> x86/crypto/ has a lot of AVX optimized code. > > Yeah, that's true, but the crypto code

Re: [PATCH net-next] modules: allow modprobe load regular elf binaries

On Sat, Mar 10, 2018 at 1:43 AM, Alexei Starovoitov <a...@fb.com> wrote: > On 3/9/18 11:37 AM, Andy Lutomirski wrote: >> >> On Fri, Mar 9, 2018 at 6:55 PM, David Miller <da...@davemloft.net> wrote: >>> >>> From: Alexei Starovoitov <a...@

Re: [PATCH net-next] modules: allow modprobe load regular elf binaries

On Fri, Mar 9, 2018 at 7:38 PM, Linus Torvalds wrote: > On Fri, Mar 9, 2018 at 11:12 AM, Linus Torvalds > wrote: >> >> How are you going to handle five processes doing the same setup concurrently? > > Side note: it's not just

Re: [PATCH net-next] modules: allow modprobe load regular elf binaries

On Fri, Mar 9, 2018 at 6:55 PM, David Miller <da...@davemloft.net> wrote: > From: Alexei Starovoitov <a...@fb.com> > Date: Fri, 9 Mar 2018 10:50:49 -0800 > >> On 3/9/18 10:23 AM, Andy Lutomirski wrote: >>> It might not be totally crazy to back it by tmpfs. &

Re: [PATCH net-next] modules: allow modprobe load regular elf binaries

> On Mar 9, 2018, at 10:17 AM, Linus Torvalds > wrote: > > > Hmm. I wish we had an "execute blob" model, but we really don't, and > it would be hard/impossible to do without pinning the pages in memory. > Why so hard? We can already execute a struct file

Re: [PATCH net-next] modules: allow modprobe load regular elf binaries

> On Mar 9, 2018, at 10:15 AM, Greg KH wrote: > > > Oh, and for the record, I like Andy's proposal as well as dumping this > into a kernel module "blob" with the exception that this now would take > up unswapable memory, which isn't the nicest and is one big

Re: [PATCH net-next] modules: allow modprobe load regular elf binaries

On Fri, Mar 9, 2018 at 3:39 PM, Alexei Starovoitov <a...@fb.com> wrote: > On 3/9/18 7:16 AM, Andy Lutomirski wrote: >>>> >>>> On Mar 8, 2018, at 9:08 PM, Alexei Starovoitov <a...@fb.com> wrote: >>>> >>>> On 3/8/18 7:54 PM, Andy Lu

Re: [PATCH net-next] modules: allow modprobe load regular elf binaries

>> On Mar 8, 2018, at 9:08 PM, Alexei Starovoitov <a...@fb.com> wrote: >> >> On 3/8/18 7:54 PM, Andy Lutomirski wrote: >> >> >> >>> On Mar 8, 2018, at 7:06 PM, Linus Torvalds <torva...@linux-foundation.org> >>> wrote:

Re: [PATCH net-next] modules: allow modprobe load regular elf binaries

> On Mar 8, 2018, at 7:06 PM, Linus Torvalds > wrote: > > > Honestly, that "read twice" thing may be what scuttles this. > Initially, I thought it was a non-issue, because anybody who controls > the module subdirectory enough to rewrite files would be in a

Re: [PATCH net-next] modules: allow modprobe load regular elf binaries

> On Mar 8, 2018, at 6:31 PM, David Miller <da...@davemloft.net> wrote: > > From: Andy Lutomirski <l...@kernel.org> > Date: Fri, 9 Mar 2018 02:12:24 + > >> First, compile your user code and emit a staitc binary. Use objdump >> fiddling or a tri

Re: [PATCH net-next] modules: allow modprobe load regular elf binaries

On Fri, Mar 9, 2018 at 1:20 AM, Alexei Starovoitov <alexei.starovoi...@gmail.com> wrote: > On Fri, Mar 09, 2018 at 12:59:36AM +0000, Andy Lutomirski wrote: >> >> Alexei, can you give an example use case? I'm sure it's upthread >> somewhere, but I'm having trouble

Re: [PATCH net-next] modules: allow modprobe load regular elf binaries

On Fri, Mar 9, 2018 at 12:57 AM, Alexei Starovoitov wrote: > On 3/8/18 4:24 PM, Kees Cook wrote: >> >> As Andy asked earlier, why not DYN too to catch PIE executables? Seems >> like forcing the userspace helper to be non-PIE would defeat some of >> the userspace defenses in use in

Re: [PATCH net-next] modules: allow modprobe load regular elf binaries

On Fri, Mar 9, 2018 at 12:24 AM, Kees Cook wrote: > How is this not marked [RFC]? :) > > On Mon, Mar 5, 2018 at 5:34 PM, Alexei Starovoitov wrote: >> As the first step in development of bpfilter project [1] the request_module() >> code is extended to allow

Re: [PATCH bpf-next v8 00/11] Landlock LSM: Toward unprivileged sandboxing

On Thu, Mar 8, 2018 at 11:51 PM, Mickaël Salaün <m...@digikod.net> wrote: > > On 07/03/2018 02:21, Andy Lutomirski wrote: >> On Tue, Mar 6, 2018 at 11:06 PM, Mickaël Salaün <m...@digikod.net> wrote: >>> >>> On 06/03/2018 23:46, Tycho Andersen wrote: >

Re: [PATCH bpf-next v8 00/11] Landlock LSM: Toward unprivileged sandboxing

On Tue, Mar 6, 2018 at 11:06 PM, Mickaël Salaün <m...@digikod.net> wrote: > > On 06/03/2018 23:46, Tycho Andersen wrote: >> On Tue, Mar 06, 2018 at 10:33:17PM +0000, Andy Lutomirski wrote: >>>>> Suppose I'm writing a container manager. I want to run "moun

Re: [PATCH bpf-next v8 00/11] Landlock LSM: Toward unprivileged sandboxing

On Tue, Mar 6, 2018 at 10:25 PM, Mickaël Salaün <m...@digikod.net> wrote: > > > On 28/02/2018 00:09, Andy Lutomirski wrote: >> On Tue, Feb 27, 2018 at 10:03 PM, Mickaël Salaün <m...@digikod.net> wrote: >>> >>> On 27/02/2018 05:36, Andy Lutomirski

Re: [PATCH net-next] modules: allow modprobe load regular elf binaries

On Tue, Mar 6, 2018 at 1:34 AM, Alexei Starovoitov wrote: > As the first step in development of bpfilter project [1] the request_module() > code is extended to allow user mode helpers to be invoked. Idea is that > user mode helpers are built as part of the kernel build and

Re: [net-next v3 1/2] bpf, seccomp: Add eBPF filter capabilities

On Mon, Feb 26, 2018 at 7:27 AM, Sargun Dhillon wrote: > This introduces the BPF_PROG_TYPE_SECCOMP bpf program type. It is meant > to be used for seccomp filters as an alternative to cBPF filters. The > program type has relatively limited capabilities in terms of helpers, > but

Re: [net-next v3 0/2] eBPF seccomp filters

On Thu, Mar 1, 2018 at 9:51 PM, Sargun Dhillon <sar...@sargun.me> wrote: > On Thu, Mar 1, 2018 at 9:44 AM, Andy Lutomirski <l...@amacapital.net> wrote: >> On Wed, Feb 28, 2018 at 7:56 PM, Daniel Borkmann <dan...@iogearbox.net> >> wrote: >>> On 02/28/201

Re: [net-next v3 0/2] eBPF seccomp filters

11:00 AM, Kees Cook wrote: >>>>>> On Tue, Feb 27, 2018 at 6:53 AM, chris hyser <chris.hy...@oracle.com> >>>>>> wrote: >>>>>>> On 02/26/2018 11:38 PM, Kees Cook wrote: >>>>>>>> On Mon, Feb 26, 2018 at 8:19 PM, Andy

Re: [PATCH bpf-next v8 08/11] landlock: Add ptrace restrictions

On Wed, Feb 28, 2018 at 12:00 AM, Mickaël Salaün <m...@digikod.net> wrote: > > On 28/02/2018 00:23, Andy Lutomirski wrote: >> On Tue, Feb 27, 2018 at 11:02 PM, Andy Lutomirski <l...@kernel.org> wrote: >>> On Tue, Feb 27, 2018 at 10:14 PM, Mickaël Salaün <m..

Re: [PATCH bpf-next v8 08/11] landlock: Add ptrace restrictions

On Tue, Feb 27, 2018 at 11:02 PM, Andy Lutomirski <l...@kernel.org> wrote: > On Tue, Feb 27, 2018 at 10:14 PM, Mickaël Salaün <m...@digikod.net> wrote: >> >> On 27/02/2018 06:01, Andy Lutomirski wrote: >>> >>> >>>> On Feb 26, 2018

Re: [net-next v3 0/2] eBPF seccomp filters

On Tue, Feb 27, 2018 at 11:10 PM, Mickaël Salaün <m...@digikod.net> wrote: > > On 27/02/2018 05:54, Andy Lutomirski wrote: >> >> >>> On Feb 26, 2018, at 8:38 PM, Kees Cook <keesc...@chromium.org> wrote: >>> >>> On Mon, Feb 26, 2018 at

Re: [PATCH bpf-next v8 00/11] Landlock LSM: Toward unprivileged sandboxing

On Tue, Feb 27, 2018 at 10:03 PM, Mickaël Salaün <m...@digikod.net> wrote: > > On 27/02/2018 05:36, Andy Lutomirski wrote: >> On Tue, Feb 27, 2018 at 12:41 AM, Mickaël Salaün <m...@digikod.net> wrote: >>> Hi, >>> >>> >>> ## Why use th

Re: [PATCH bpf-next v8 08/11] landlock: Add ptrace restrictions

On Tue, Feb 27, 2018 at 10:14 PM, Mickaël Salaün <m...@digikod.net> wrote: > > On 27/02/2018 06:01, Andy Lutomirski wrote: >> >> >>> On Feb 26, 2018, at 8:17 PM, Andy Lutomirski <l...@amacapital.net> wrote: >>> >>>> On Tue, Feb 2

Re: [PATCH bpf-next v8 05/11] seccomp,landlock: Enforce Landlock programs per process hierarchy

On Tue, Feb 27, 2018 at 5:30 PM, Casey Schaufler <ca...@schaufler-ca.com> wrote: > On 2/27/2018 8:39 AM, Andy Lutomirski wrote: >> On Tue, Feb 27, 2018 at 5:32 AM, Alexei Starovoitov >> <alexei.starovoi...@gmail.com> wrote: >>> [ Snip ] >> An earlier

Re: [PATCH bpf-next v8 05/11] seccomp,landlock: Enforce Landlock programs per process hierarchy

On Tue, Feb 27, 2018 at 5:32 AM, Alexei Starovoitov <alexei.starovoi...@gmail.com> wrote: > On Tue, Feb 27, 2018 at 05:20:55AM +0000, Andy Lutomirski wrote: >> On Tue, Feb 27, 2018 at 4:54 AM, Alexei Starovoitov >> <alexei.starovoi...@gmail.com> wrote: >> > On T

Re: [PATCH bpf-next v8 05/11] seccomp,landlock: Enforce Landlock programs per process hierarchy

On Tue, Feb 27, 2018 at 4:54 AM, Alexei Starovoitov <alexei.starovoi...@gmail.com> wrote: > On Tue, Feb 27, 2018 at 04:40:34AM +0000, Andy Lutomirski wrote: >> On Tue, Feb 27, 2018 at 2:08 AM, Alexei Starovoitov >> <alexei.starovoi...@gmail.com> wrote: >> > On T

Re: [PATCH bpf-next v8 08/11] landlock: Add ptrace restrictions

> On Feb 26, 2018, at 8:17 PM, Andy Lutomirski <l...@amacapital.net> wrote: > >> On Tue, Feb 27, 2018 at 12:41 AM, Mickaël Salaün <m...@digikod.net> wrote: >> A landlocked process has less privileges than a non-landlocked process >> and must then be sub

Re: [net-next v3 0/2] eBPF seccomp filters

> On Feb 26, 2018, at 8:38 PM, Kees Cook <keesc...@chromium.org> wrote: > > On Mon, Feb 26, 2018 at 8:19 PM, Andy Lutomirski <l...@amacapital.net> wrote: >>> On Feb 26, 2018, at 3:20 PM, Kees Cook <keesc...@chromium.org> wrote: >>> >>&g

Re: [PATCH bpf-next v8 05/11] seccomp,landlock: Enforce Landlock programs per process hierarchy

On Tue, Feb 27, 2018 at 2:08 AM, Alexei Starovoitov wrote: > On Tue, Feb 27, 2018 at 01:41:15AM +0100, Mickaël Salaün wrote: >> The seccomp(2) syscall can be used by a task to apply a Landlock program >> to itself. As a seccomp filter, a Landlock program is enforced

Re: [PATCH bpf-next v8 00/11] Landlock LSM: Toward unprivileged sandboxing

On Tue, Feb 27, 2018 at 12:41 AM, Mickaël Salaün wrote: > Hi, > > This eight series is a major revamp of the Landlock design compared to > the previous series [1]. This enables more flexibility and granularity > of access control with file paths. It is now possible to enforce an

Re: [net-next v3 0/2] eBPF seccomp filters

> On Feb 26, 2018, at 3:20 PM, Kees Cook wrote: > > On Mon, Feb 26, 2018 at 3:04 PM, Alexei Starovoitov > wrote: >>> On Mon, Feb 26, 2018 at 07:26:54AM +, Sargun Dhillon wrote: >>> This patchset enables seccomp filters to be written in

Re: [PATCH bpf-next v8 08/11] landlock: Add ptrace restrictions

s on a > target process, a landlocked process must have a subset of the target > process' rules. > > Signed-off-by: Mickaël Salaün <m...@digikod.net> > Cc: Alexei Starovoitov <a...@kernel.org> > Cc: Andy Lutomirski <l...@amacapital.net> > Cc: Daniel Bor

Re: [PATCH net-next 0/3] eBPF Seccomp filters

> On Feb 14, 2018, at 8:30 PM, Alexei Starovoitov > wrote: > > On Wed, Feb 14, 2018 at 10:32:22AM -0700, Tycho Andersen wrote: What's the reason for adding eBPF support? seccomp shouldn't need it, and it only makes the code more complex. I'd rather

Re: [PATCH net-next 0/3] eBPF Seccomp filters

On Tue, Feb 13, 2018 at 3:47 PM, Kees Cook wrote: > On Tue, Feb 13, 2018 at 7:42 AM, Sargun Dhillon wrote: >> This patchset enables seccomp filters to be written in eBPF. Although, >> this patchset doesn't introduce much of the functionality enabled by >>

Re: [PATCH V2] Fix a sleep-in-atomic bug in shash_setkey_unaligned

On Mon, Oct 2, 2017 at 10:26 PM, Herbert Xu <herb...@gondor.apana.org.au> wrote: > On Mon, Oct 02, 2017 at 09:18:24PM -0700, Andy Lutomirski wrote: >> > On Oct 2, 2017, at 7:25 PM, Jia-Ju Bai <baijiaju1...@163.com> wrote: >> > >> > The SCTP program may sle

Re: [PATCH V2] Fix a sleep-in-atomic bug in shash_setkey_unaligned

> On Oct 2, 2017, at 7:25 PM, Jia-Ju Bai wrote: > > The SCTP program may sleep under a spinlock, and the function call path is: > sctp_generate_t3_rtx_event (acquire the spinlock) > sctp_do_sm >sctp_side_effects > sctp_cmd_interpreter >sctp_make_init_ack >

Re: [kernel-hardening] [PATCH v4 next 0/3] modules: automatic module loading restrictions

On Tue, May 23, 2017 at 11:36 AM, Kees Cook wrote: > On Tue, May 23, 2017 at 12:48 AM, Solar Designer wrote: >> For modules_autoload_mode=2, we already seem to have the equivalent of >> modprobe=/bin/true (or does it differ subtly, maybe in return

Re: [kernel-hardening] [PATCH v4 next 0/3] modules: automatic module loading restrictions

On Mon, May 22, 2017 at 4:07 PM, Kees Cook wrote: > On Mon, May 22, 2017 at 12:55 PM, Djalal Harouni wrote: >> On Mon, May 22, 2017 at 6:43 PM, Solar Designer wrote: >>> On Mon, May 22, 2017 at 03:49:15PM +0200, Djalal Harouni wrote:

Re: [net-next PATCH v2 8/8] net: Introduce SO_INCOMING_NAPI_ID

On Thu, Mar 23, 2017 at 5:58 PM, Alexander Duyck <alexander.du...@gmail.com> wrote: > On Thu, Mar 23, 2017 at 3:43 PM, Andy Lutomirski <l...@kernel.org> wrote: >> On Thu, Mar 23, 2017 at 2:38 PM, Alexander Duyck >> <alexander.du...@gmail.com> wrote: >>&g

Re: [net-next PATCH v2 8/8] net: Introduce SO_INCOMING_NAPI_ID

On Thu, Mar 23, 2017 at 2:38 PM, Alexander Duyck wrote: > From: Sridhar Samudrala > > This socket option returns the NAPI ID associated with the queue on which > the last frame is received. This information can be used by the apps to >

Re: [PATCH v5 06/10] seccomp,landlock: Handle Landlock events per process hierarchy

On Thu, Mar 2, 2017 at 4:48 PM, Mickaël Salaün <m...@digikod.net> wrote: > > On 02/03/2017 17:36, Andy Lutomirski wrote: >> On Wed, Mar 1, 2017 at 3:28 PM, Mickaël Salaün <m...@digikod.net> wrote: >>> >>> >>> On 01/03/2017 23:20, Andy Lutomirski

Re: [PATCH RFC v2 00/12] socket sendmsg MSG_ZEROCOPY

On Tue, Feb 28, 2017 at 7:28 PM, David Miller <da...@davemloft.net> wrote: > From: Andy Lutomirski <l...@amacapital.net> > Date: Tue, 28 Feb 2017 13:06:49 -0800 > >> On Tue, Feb 28, 2017 at 12:43 PM, Willem de Bruijn >> <willemdebruijn.ker...@gmail.com> wro

Re: [PATCH v5 06/10] seccomp,landlock: Handle Landlock events per process hierarchy

On Wed, Mar 1, 2017 at 3:28 PM, Mickaël Salaün <m...@digikod.net> wrote: > > > On 01/03/2017 23:20, Andy Lutomirski wrote: >> On Wed, Mar 1, 2017 at 2:14 PM, Mickaël Salaün <m...@digikod.net> wrote: >>> >>> On 28/02/2017 21:01, Andy Lutomirski wrote:

Re: [PATCH v5 06/10] seccomp,landlock: Handle Landlock events per process hierarchy

On Wed, Mar 1, 2017 at 2:14 PM, Mickaël Salaün <m...@digikod.net> wrote: > > On 28/02/2017 21:01, Andy Lutomirski wrote: >> On Tue, Feb 21, 2017 at 5:26 PM, Mickaël Salaün <m...@digikod.net> wrote: >>> The seccomp(2) syscall can be use to apply a Landloc

Re: [PATCH RFC v2 00/12] socket sendmsg MSG_ZEROCOPY

On Tue, Feb 28, 2017 at 2:40 PM, Eric Dumazet <eric.duma...@gmail.com> wrote: > On Tue, 2017-02-28 at 14:25 -0800, Andy Lutomirski wrote: >> On Tue, Feb 28, 2017 at 1:47 PM, Eric Dumazet <eric.duma...@gmail.com> wrote: >> > On Tue, 2017-02-28 at 13:09 -0800, Andy Lut

Re: [PATCH RFC v2 00/12] socket sendmsg MSG_ZEROCOPY

On Tue, Feb 28, 2017 at 1:47 PM, Eric Dumazet <eric.duma...@gmail.com> wrote: > On Tue, 2017-02-28 at 13:09 -0800, Andy Lutomirski wrote: > >> Does this mean that a user program that does a zerocopy send can cause >> a retransmitted segment to contain different data than

Re: [PATCH v5 06/10] seccomp,landlock: Handle Landlock events per process hierarchy

On Tue, Feb 21, 2017 at 5:26 PM, Mickaël Salaün wrote: > The seccomp(2) syscall can be use to apply a Landlock rule to the > current process. As with a seccomp filter, the Landlock rule is enforced > for all its future children. An inherited rule tree can be updated >

Re: [PATCH RFC v2 00/12] socket sendmsg MSG_ZEROCOPY

On Tue, Feb 28, 2017 at 12:43 PM, Willem de Bruijn wrote: > >> I can see this working if you have a special type of skb that >> indicates that the data might be concurrently written and have all the >> normal skb APIs (including, especially, anything that clones

Re: [PATCH RFC v2 00/12] socket sendmsg MSG_ZEROCOPY

On Tue, Feb 28, 2017 at 12:43 PM, Willem de Bruijn <willemdebruijn.ker...@gmail.com> wrote: > On Tue, Feb 28, 2017 at 2:46 PM, Andy Lutomirski <l...@amacapital.net> wrote: >> On Mon, Feb 27, 2017 at 10:57 AM, Michael Kerrisk >> <mtk.manpa...@gmail.com> wrote: >

Re: [PATCH RFC v2 00/12] socket sendmsg MSG_ZEROCOPY

On Mon, Feb 27, 2017 at 10:57 AM, Michael Kerrisk wrote: > [CC += linux-...@vger.kernel.org] > > Hi Willem > >> On a send call with MSG_ZEROCOPY, the kernel pins the user pages and >> creates skbuff fragments directly from these pages. On tx completion, >> it notifies the

Re: [PATCH v5 10/10] landlock: Add user and kernel documentation for Landlock

On Tue, Feb 21, 2017 at 5:26 PM, Mickaël Salaün <m...@digikod.net> wrote: > This documentation can be built with the Sphinx framework. > > Signed-off-by: Mickaël Salaün <m...@digikod.net> > Cc: Alexei Starovoitov <a...@kernel.org> > Cc: Andy Lutomirski <l...@a

Re: [PATCH v4 net] bpf: add bpf_sk_netns_id() helper

ased and have global scope. I would like to be > able to correlate, for example, FIB lookups within a single network > namespace. Having an id that I could filter on when collecting or match > when dumping them goes a long way. Why wouldn't an id relative to your logging program work? Global ids are problematic because they are incompatible with tools like CRIU. -- Andy Lutomirski AMA Capital Management, LLC

Re: [PATCH v2 net] bpf: introduce BPF_F_ALLOW_OVERRIDE flag

rridable prog to >> /foo"); >> + goto err; >> + } >> + >> + if (bpf_prog_attach(drop_prog, foo, BPF_CGROUP_INET_EGRESS, 0)) { >> + log_err("Attaching different non-overridable prog to /foo"); >> + goto err; >> + } >> + >> goto out; >> >> err: >> @@ -132,5 +188,9 @@ int main(int argc, char **argv) >> close(foo); >> close(bar); >> cleanup_cgroup_environment(); >> + if (!rc) >> + printf("PASS\n"); >> + else >> + printf("FAIL\n"); >> return rc; >> } >> diff --git a/samples/bpf/test_cgrp2_sock.c b/samples/bpf/test_cgrp2_sock.c >> index 0791b949cbe4..c3cfb23e23b5 100644 >> --- a/samples/bpf/test_cgrp2_sock.c >> +++ b/samples/bpf/test_cgrp2_sock.c >> @@ -75,7 +75,7 @@ int main(int argc, char **argv) >> return EXIT_FAILURE; >> } >> >> - ret = bpf_prog_attach(prog_fd, cg_fd, BPF_CGROUP_INET_SOCK_CREATE); >> + ret = bpf_prog_attach(prog_fd, cg_fd, BPF_CGROUP_INET_SOCK_CREATE, 0); >> if (ret < 0) { >> printf("Failed to attach prog to cgroup: '%s'\n", >> strerror(errno)); >> diff --git a/samples/bpf/test_cgrp2_sock2.c b/samples/bpf/test_cgrp2_sock2.c >> index 455ef0d06e93..db036077b644 100644 >> --- a/samples/bpf/test_cgrp2_sock2.c >> +++ b/samples/bpf/test_cgrp2_sock2.c >> @@ -55,7 +55,7 @@ int main(int argc, char **argv) >> } >> >> ret = bpf_prog_attach(prog_fd[filter_id], cg_fd, >> - BPF_CGROUP_INET_SOCK_CREATE); >> + BPF_CGROUP_INET_SOCK_CREATE, 0); >> if (ret < 0) { >> printf("Failed to attach prog to cgroup: '%s'\n", >> strerror(errno)); >> diff --git a/tools/lib/bpf/bpf.c b/tools/lib/bpf/bpf.c >> index 3ddb58a36d3c..ae752fa4eaa7 100644 >> --- a/tools/lib/bpf/bpf.c >> +++ b/tools/lib/bpf/bpf.c >> @@ -168,7 +168,8 @@ int bpf_obj_get(const char *pathname) >> return sys_bpf(BPF_OBJ_GET, , sizeof(attr)); >> } >> >> -int bpf_prog_attach(int prog_fd, int target_fd, enum bpf_attach_type type) >> +int bpf_prog_attach(int prog_fd, int target_fd, enum bpf_attach_type type, >> + unsigned int flags) >> { >> union bpf_attr attr; >> >> @@ -176,6 +177,7 @@ int bpf_prog_attach(int prog_fd, int target_fd, enum >> bpf_attach_type type) >> attr.target_fd = target_fd; >> attr.attach_bpf_fd = prog_fd; >> attr.attach_type = type; >> + attr.attach_flags = flags; >> >> return sys_bpf(BPF_PROG_ATTACH, , sizeof(attr)); >> } >> diff --git a/tools/lib/bpf/bpf.h b/tools/lib/bpf/bpf.h >> index a2f9853dd882..4ac6c4b84100 100644 >> --- a/tools/lib/bpf/bpf.h >> +++ b/tools/lib/bpf/bpf.h >> @@ -41,7 +41,8 @@ int bpf_map_delete_elem(int fd, void *key); >> int bpf_map_get_next_key(int fd, void *key, void *next_key); >> int bpf_obj_pin(int fd, const char *pathname); >> int bpf_obj_get(const char *pathname); >> -int bpf_prog_attach(int prog_fd, int attachable_fd, enum bpf_attach_type >> type); >> +int bpf_prog_attach(int prog_fd, int attachable_fd, enum bpf_attach_type >> type, >> + unsigned int flags); >> int bpf_prog_detach(int attachable_fd, enum bpf_attach_type type); >> >> >> > -- Andy Lutomirski AMA Capital Management, LLC

Re: [RFC PATCH net] bpf: introduce BPF_F_ALLOW_OVERRIDE flag

} > > - return 0; > + return ret; > } > #endif /* CONFIG_CGROUP_BPF */ > > diff --git a/kernel/cgroup.c b/kernel/cgroup.c > index 688dd02af985..53bbca7c4859 100644 > --- a/kernel/cgroup.c > +++ b/kernel/cgroup.c > @@ -6498,15 +6498,16 @@ static __init int cgroup_namespaces_init(void) > subsys_initcall(cgroup_namespaces_init); > > #ifdef CONFIG_CGROUP_BPF > -void cgroup_bpf_update(struct cgroup *cgrp, > - struct bpf_prog *prog, > - enum bpf_attach_type type) > +int cgroup_bpf_update(struct cgroup *cgrp, struct bpf_prog *prog, > + enum bpf_attach_type type, bool overridable) > { > struct cgroup *parent = cgroup_parent(cgrp); > + int ret; > > mutex_lock(_mutex); > - __cgroup_bpf_update(cgrp, parent, prog, type); > + ret = __cgroup_bpf_update(cgrp, parent, prog, type, overridable); > mutex_unlock(_mutex); > + return ret; > } > #endif /* CONFIG_CGROUP_BPF */ > > -- > 2.8.0 > -- Andy Lutomirski AMA Capital Management, LLC

Re: [PATCH v2 net] bpf: add bpf_sk_netns_id() helper

On Mon, Feb 6, 2017 at 5:42 PM, Alexei Starovoitov <alexei.starovoi...@gmail.com> wrote: > On Sat, Feb 04, 2017 at 08:17:57PM -0800, Andy Lutomirski wrote: >> On Sat, Feb 4, 2017 at 8:05 PM, Alexei Starovoitov >> <alexei.starovoi...@gmail.com> wrote: >> > On S

Re: [PATCH v3 net] bpf: add bpf_sk_netns_id() helper

On Sun, Feb 5, 2017 at 11:24 AM, David Ahern wrote: > On 2/3/17 8:34 PM, Alexei Starovoitov wrote: >> Therefore introduce 'u64 bpf_sk_netns_id(sk);' helper. It returns >> unique value that identifies netns of given socket or dev_net(skb->dev) >> The upper 32-bits of the

Re: [PATCH net] bpf: expose netns inode to bpf programs

On Sat, Feb 4, 2017 at 8:37 PM, Alexei Starovoitov <alexei.starovoi...@gmail.com> wrote: > On Sat, Feb 04, 2017 at 07:54:20PM -0800, Andy Lutomirski wrote: >> >> I've repeatedly asked how you plan to make a "don't override" flag >> have sensible semantics

Re: [PATCH v2 net] bpf: add bpf_sk_netns_id() helper

On Sat, Feb 4, 2017 at 8:05 PM, Alexei Starovoitov <alexei.starovoi...@gmail.com> wrote: > On Sat, Feb 04, 2017 at 07:33:14PM -0800, Andy Lutomirski wrote: >> On Sat, Feb 4, 2017 at 7:25 PM, Alexei Starovoitov >> <alexei.starovoi...@gmail.com> wrote: >> > On S

Re: [PATCH net] bpf: expose netns inode to bpf programs

On Sat, Feb 4, 2017 at 7:48 PM, Alexei Starovoitov <alexei.starovoi...@gmail.com> wrote: > On Sat, Feb 04, 2017 at 07:27:01PM -0800, Andy Lutomirski wrote: >> On Sat, Feb 4, 2017 at 7:10 PM, Alexei Starovoitov >> <alexei.starovoi...@gmail.com> wrote: >> > On S

Re: [PATCH net] bpf: expose netns inode to bpf programs

On Sat, Feb 4, 2017 at 7:35 PM, Alexei Starovoitov <alexei.starovoi...@gmail.com> wrote: > On Sat, Feb 04, 2017 at 07:22:03PM -0800, Andy Lutomirski wrote: >> On Sat, Feb 4, 2017 at 7:18 PM, Alexei Starovoitov >> <alexei.starovoi...@gmail.com> wrote: >> > On S

Re: [PATCH v2 net] bpf: add bpf_sk_netns_id() helper

On Sat, Feb 4, 2017 at 7:25 PM, Alexei Starovoitov <alexei.starovoi...@gmail.com> wrote: > On Sat, Feb 04, 2017 at 09:15:10AM -0800, Andy Lutomirski wrote: >> On Fri, Feb 3, 2017 at 5:22 PM, Alexei Starovoitov <a...@fb.com> wrote: >> > Note that all bpf programs t

Re: [PATCH net] bpf: expose netns inode to bpf programs

On Sat, Feb 4, 2017 at 7:10 PM, Alexei Starovoitov <alexei.starovoi...@gmail.com> wrote: > On Sat, Feb 04, 2017 at 09:07:19AM -0800, Andy Lutomirski wrote: >> >> can see a namespaced view of the world. For this to work, presumably >> >> we need to make sure that

Re: [PATCH net] bpf: expose netns inode to bpf programs

On Sat, Feb 4, 2017 at 7:18 PM, Alexei Starovoitov <alexei.starovoi...@gmail.com> wrote: > On Sat, Feb 04, 2017 at 09:08:38AM -0800, Andy Lutomirski wrote: >> > So use-case would be that someone wants to attach the very same >> > prog via tc to various netdevs

Re: [PATCH v2 net] bpf: add bpf_sk_netns_id() helper

On Fri, Feb 3, 2017 at 5:22 PM, Alexei Starovoitov wrote: > Note that all bpf programs types are global. I don't think this has a clear enough meaning to work with. In particular, I think that, if you have some software that installs cgroup+bpf programs and you run it in a

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Fri, Feb 3, 2017 at 3:21 PM, Alexei Starovoitov <alexei.starovoi...@gmail.com> wrote: > On Fri, Feb 03, 2017 at 01:07:39PM -0800, Andy Lutomirski wrote: >> >> Is there any plan to address this? If not, I'll try to write that >> patch this weekend. > > yes.

Re: [PATCH net] bpf: expose netns inode to bpf programs

On Fri, Feb 3, 2017 at 3:42 PM, Daniel Borkmann wrote: > On 02/04/2017 12:06 AM, Alexei Starovoitov wrote: >> >> On Fri, Feb 03, 2017 at 10:56:43PM +0100, Daniel Borkmann wrote: >>> >>> On 01/26/2017 04:27 AM, Alexei Starovoitov wrote: in cases where bpf programs

Re: [PATCH net] bpf: expose netns inode to bpf programs

On Fri, Feb 3, 2017 at 3:08 PM, Alexei Starovoitov <alexei.starovoi...@gmail.com> wrote: > On Fri, Feb 03, 2017 at 01:00:47PM -0800, Andy Lutomirski wrote: >> >> ISTM any ability to migrate namespaces and to migrate eBPF programs >> that know about namespaces needs to h

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Mon, Jan 23, 2017 at 12:20 PM, Andy Lutomirski <l...@amacapital.net> wrote: > On Sun, Jan 22, 2017 at 8:31 PM, Alexei Starovoitov > <alexei.starovoi...@gmail.com> wrote: >> On Thu, Jan 19, 2017 at 08:04:59PM -0800, Andy Lutomirski wrote: >>> restricting the typ

Re: [PATCH net] bpf: expose netns inode to bpf programs

On Thu, Feb 2, 2017 at 8:33 PM, Eric W. Biederman <ebied...@xmission.com> wrote: > Alexei Starovoitov <a...@fb.com> writes: > >> On 1/26/17 11:07 AM, Andy Lutomirski wrote: >>> On Thu, Jan 26, 2017 at 10:32 AM, Alexei Starovoitov <a...@fb.com> wrote: >>

Re: [PATCH net] bpf: expose netns inode to bpf programs

On Thu, Jan 26, 2017 at 10:32 AM, Alexei Starovoitov <a...@fb.com> wrote: > On 1/26/17 10:12 AM, Andy Lutomirski wrote: >> >> On Thu, Jan 26, 2017 at 9:46 AM, Alexei Starovoitov <a...@fb.com> wrote: >>> >>> On 1/26/17 8:37 AM, Andy Lutomirski wrote: &g

Re: [PATCH net] bpf: expose netns inode to bpf programs

On Thu, Jan 26, 2017 at 9:46 AM, Alexei Starovoitov <a...@fb.com> wrote: > On 1/26/17 8:37 AM, Andy Lutomirski wrote: >>> >>> Think of bpf programs as safe kernel modules. They don't have >>> confined boundaries and program authors, if not careful, can sho

Re: [PATCH net] bpf: expose netns inode to bpf programs

Hi Linus- Can you weigh in here before we get stuck in a potentially unfortunate place? On Wed, Jan 25, 2017 at 10:23 PM, Alexei Starovoitov wrote: > On 1/25/17 9:46 PM, Eric W. Biederman wrote: >> >> Alexei Starovoitov writes: >> [...] >>> Similarly TC

Re: [PATCH v2] bpf: Restrict cgroup bpf hooks to the init netns

On Tue, Jan 24, 2017 at 4:11 PM, Alexei Starovoitov <alexei.starovoi...@gmail.com> wrote: > On Tue, Jan 24, 2017 at 01:24:54PM -0800, Andy Lutomirski wrote: >> On Tue, Jan 24, 2017 at 12:29 PM, David Ahern <d...@cumulusnetworks.com> >> wrote: >> > >> &

Re: [PATCH v2] bpf: Restrict cgroup bpf hooks to the init netns

On Tue, Jan 24, 2017 at 12:29 PM, David Ahern wrote: > > Users do not run around exec'ing commands in random network contexts > (namespace, vrf, device, whatever) and expect them to just work. I worked on some code once (deployed in production, even!) that calls

Re: [PATCH v2] bpf: Restrict cgroup bpf hooks to the init netns

On Tue, Jan 24, 2017 at 9:48 AM, Alexei Starovoitov <alexei.starovoi...@gmail.com> wrote: > On Mon, Jan 23, 2017 at 08:32:02PM -0800, Andy Lutomirski wrote: >> On Mon, Jan 23, 2017 at 8:05 PM, David Ahern <d...@cumulusnetworks.com> >> wrote: >> > On 1/

Re: [PATCH v2] bpf: Restrict cgroup bpf hooks to the init netns

On Mon, Jan 23, 2017 at 8:05 PM, David Ahern <d...@cumulusnetworks.com> wrote: > On 1/23/17 8:37 PM, Andy Lutomirski wrote: >> Yes, it is a bug because cgroup+bpf causes unwitting programs to be >> subject to BPF code installed by a different, potentially unrelated >

Re: [PATCH v2] bpf: Restrict cgroup bpf hooks to the init netns

On Mon, Jan 23, 2017 at 8:10 PM, David Ahern <d...@cumulusnetworks.com> wrote: > On 1/23/17 7:39 PM, Andy Lutomirski wrote: >> I'm not sure I followed what you meant. If I understood right (which >> is a big if) you're saying that ip vrf when run in a netns works >>

Re: [PATCH v2] bpf: Restrict cgroup bpf hooks to the init netns

On Mon, Jan 23, 2017 at 7:13 PM, Alexei Starovoitov <alexei.starovoi...@gmail.com> wrote: > On Mon, Jan 23, 2017 at 06:42:27PM -0800, Andy Lutomirski wrote: >> Please explain how the change results in a broken ABI and how the >> current ABI is better. I gave a fully work

Re: [PATCH v2] bpf: Restrict cgroup bpf hooks to the init netns

On Mon, Jan 23, 2017 at 6:09 PM, Alexei Starovoitov <alexei.starovoi...@gmail.com> wrote: > On Mon, Jan 23, 2017 at 12:36:08PM -0800, Andy Lutomirski wrote: >> To see how cgroup+bpf interacts with network namespaces, I wrote a >> little program called show_bind

Re: [PATCH v2] bpf: Restrict cgroup bpf hooks to the init netns

On Mon, Jan 23, 2017 at 6:31 PM, David Ahern wrote: > On 1/23/17 7:09 PM, Alexei Starovoitov wrote: >>> + */ >>> +if (current->nsproxy->net_ns != _net) >>> +return -EINVAL; >> >> this restriction I actually don't mind, since it indeed can be >>

Re: [PATCH v2] bpf: Restrict cgroup bpf hooks to the init netns

On Mon, Jan 23, 2017 at 1:03 PM, David Ahern <d...@cumulusnetworks.com> wrote: > On 1/23/17 1:36 PM, Andy Lutomirski wrote: >> To see how cgroup+bpf interacts with network namespaces, I wrote a >> little program called show_bind that calls getsockopt(..., >> SO_BI

[PATCH v2] bpf: Restrict cgroup bpf hooks to the init netns

global if necessary. Global hooks should presumably be constrained so that they can't write to any ifindex fields. Cc: Daniel Borkmann <dan...@iogearbox.net> Cc: Alexei Starovoitov <a...@kernel.org> Cc: David Ahern <d...@cumulusnetworks.com> Signed-off-by: Andy Lutomirski <l...@ker

[PATCH] bpf: Restrict cgroup bpf hooks to the init netns

Daniel Borkmann <dan...@iogearbox.net> Cc: Alexei Starovoitov <a...@kernel.org> Cc: David Ahern <d...@cumulusnetworks.com> Signed-off-by: Andy Lutomirski <l...@kernel.org> --- DaveM, this mitigates a bug in a feature that's new in 4.10, and the bug can be hit using current iproute2 -g

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Sun, Jan 22, 2017 at 8:31 PM, Alexei Starovoitov <alexei.starovoi...@gmail.com> wrote: > On Thu, Jan 19, 2017 at 08:04:59PM -0800, Andy Lutomirski wrote: >> On Thu, Jan 19, 2017 at 6:39 PM, Alexei Starovoitov >> <alexei.starovoi...@gmail.com> wrote: >> > On W

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Thu, Jan 19, 2017 at 6:39 PM, Alexei Starovoitov <alexei.starovoi...@gmail.com> wrote: > On Wed, Jan 18, 2017 at 06:29:22PM -0800, Andy Lutomirski wrote: >> I think it could work by making a single socket cgroup controller that >> handles all cgroup things that are boun

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

On Wed, Jan 18, 2017 at 4:59 PM, Tejun Heo <t...@kernel.org> wrote: > Hello, Andy. > > On Wed, Jan 18, 2017 at 04:18:04PM -0800, Andy Lutomirski wrote: >> To map cgroup -> hook, a simple array in each cgroup structure works. >> To map (cgroup, netns) -> hook fun

  1   2   3   >