lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <594C5065.2010900@iogearbox.net>
Date:   Fri, 23 Jun 2017 01:19:01 +0200
From:   Daniel Borkmann <daniel@...earbox.net>
To:     Lawrence Brakmo <brakmo@...com>, netdev <netdev@...r.kernel.org>
CC:     Kernel Team <Kernel-team@...com>, Blake Matheny <bmatheny@...com>,
        Alexei Starovoitov <ast@...com>,
        David Ahern <dsa@...ulusnetworks.com>
Subject: Re: [PATCH net-next v3 01/15] bpf: BPF support for sock_ops

On 06/23/2017 12:58 AM, Lawrence Brakmo wrote:
[...]
> Daniel, I see value for having a global program, so I would like to keep that. When
> this patchset is accepted, I will submit one that adds support for per cgroup
> sock_ops programs, with the option to use the global one if none is
> specified for a cgroup. We could also have the option of the cgroup sock_ops
> program choosing if the global program should run for a particular op based on
> its return value. We can iron it out the details when that patch is submitted.

Hm, could you elaborate on the value part compared to per cgroups ops?
My understanding is that per cgroup would already be a proper superset
of just the global one anyway, so why not going with that in the first
place since you're working on it?

What would be the additional value? How would global vs per cgroup one
interact with each other in terms of enforcement e.g., there's already
semantics in place for cgroups descendants, would it be that we set
TCP parameters twice or would you disable the global one altogether?
Just wondering as you could avoid these altogether with going via cgroups
initially.

Thanks,
Daniel

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ