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] [day] [month] [year] [list]
Date:   Thu, 20 Oct 2016 23:32:11 -0600
From:   David Ahern <dsa@...ulusnetworks.com>
To:     Daniel Mack <daniel@...que.org>, htejun@...com,
        daniel@...earbox.net, ast@...com,
        Pablo Neira Ayuso <pablo@...filter.org>
Cc:     davem@...emloft.net, kafai@...com, fw@...len.de,
        pablo@...filter.org, harald@...hat.com, netdev@...r.kernel.org,
        sargun@...gun.me, cgroups@...r.kernel.org
Subject: Re: [PATCH v6 0/6] Add eBPF hooks for cgroups

On 9/19/16 10:43 AM, Daniel Mack wrote:
> This is v6 of the patch set to allow eBPF programs for network
> filtering and accounting to be attached to cgroups, so that they apply
> to all sockets of all tasks placed in that cgroup. The logic also
> allows to be extendeded for other cgroup based eBPF logic.
> 
> 
> Changes from v5:
> 
> * The eBPF programs now operate on L3 rather than on L2 of the packets,
>   and the egress hooks were moved from __dev_queue_xmit() to
>   ip*_output().
> 
> * For BPF_PROG_TYPE_CGROUP_SOCKET, disallow direct access to the skb
>   through BPF_LD_[ABS|IND] instructions, but hook up the
>   bpf_skb_load_bytes() access helper instead. Thanks to Daniel Borkmann
>   for the help.

It's been a month since the last response or update to this series. Any progress in resolving the resistance to hook locations?

As I mentioned in Tokyo I need a solution for VRF that allows running processes in a VRF context -- meaning a process inherits a default sk_bound_dev_if for any AF_INET{6} sockets opened. Right now we (Cumulus) are using an l3mdev cgroup, something that Tejun pushed back on earlier this year. I strongly believe that cgroups provide the right infrastructure for this feature and looking at options. I'm sure a few people will chuckle about this, but I do have another solution that leverages this patchset -- a bpf program on a cgroup that sets sk_bound_dev_if. So, what's the likelihood of this patchset making 4.10 (or any other release)?

Thanks,
David

Powered by blists - more mailing lists