netdev - Re: [PATCH net-next v3 01/15] bpf: BPF support for sock

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]

Date:   Wed, 28 Jun 2017 17:45:18 +0000
From:   Lawrence Brakmo <brakmo@...com>
To:     Daniel Borkmann <daniel@...earbox.net>,
        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 6/23/17, 2:15 PM, "Daniel Borkmann" <daniel@...earbox.net> wrote:

    On 06/23/2017 01:57 AM, Lawrence Brakmo wrote:
    > On 6/22/17, 4:19 PM, "netdev-owner@...r.kernel.org on behalf of Daniel Borkmann" <netdev-owner@...r.kernel.org on behalf of daniel@...earbox.net> wrote:
    >
    >      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
    >
    > Well, for starters the global program will work even if CONFIG_CGROUP_BPF is
    > not defined. It is also an easier concept for when a global program is all that
    
    Otoh, major distros are highly likely to enable this on by default anyway.
    
    > is required. But I also had in mind that behaviors that were in common for
    > most cgroup programs could be handled by the global program instead of
    > adding it to all cgroup programs. In this scenario the global program
    > represents the default behavior that can be override by the cgroup
    > program (per op). For example, the cgroup program could return a value
    > to indicate that that op should be passed to the global program.
    
    But then you would need to go through two program passes for setting
    such parameters? Other option could be to make the per cgroup ops more
    fine grained and use the effective one that was inherited for delegating
    to default ops. My gut feeling is just that this makes interactions to
    manage this and enforcement in combination with the later planned per
    cgroups ops more complex if the same use-case could indeed be resolved
    with per cgroups only.
    
Daniel, thank you for the feedback. I just submitted a new patch set without
the global program and using bpf cgroups framework.

    > I agree 100% with you on the value of cgroup programs, but I just happen
    > to think there is also value in the global program.
    >
    > Thanks,
    > Lawrence