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  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:   Mon, 27 Jan 2020 20:43:09 -0700
From:   David Ahern <dsahern@...il.com>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     Toke Høiland-Jørgensen <toke@...hat.com>,
        David Ahern <dsahern@...nel.org>, netdev@...r.kernel.org,
        prashantbhole.linux@...il.com, jasowang@...hat.com,
        davem@...emloft.net, jbrouer@...hat.com, mst@...hat.com,
        toshiaki.makita1@...il.com, daniel@...earbox.net,
        john.fastabend@...il.com, ast@...nel.org, kafai@...com,
        songliubraving@...com, yhs@...com, andriin@...com,
        David Ahern <dahern@...italocean.com>
Subject: Re: [PATCH bpf-next 03/12] net: Add IFLA_XDP_EGRESS for XDP programs
 in the egress path

On 1/27/20 7:16 AM, Jakub Kicinski wrote:
>> I want to run an ebpf program in the Tx path of the NIC regardless of
>> how the packet arrived at the device -- as an skb or an xdp_frame. There
>> are options for running programs on skb-based packets (e.g., tc). There
>> are *zero* options for manipulating/controlling/denying xdp_frames -
>> e.g., one REDIRECTED from an ingress device.
> 
> Okay - so no precise use case.  You can run the same program at the 

For the sake of this discussion, consider a per-VM, per-tap device ebpf
program for firewall / ACL / traffic verification (packet manipulation
is also a possibility). Small, singly focused ebpf programs - attached
at startup, driven by maps, cleaned up when the tap device is destroyed.
(Remember: Tx for tap device is ingress to a VM.)

Small, singly focused programs only run for traffic to be delivered to
the VM. Setup is easy; cleanup automatic. How the traffic got there
could vary - from a bridge (L2 forwarding), the host stack (L3 routing),
or an XDP program on the host's NICs. It could have arrived at the host
with an encap header which is removed and the inner packet forwarded to
the VM.

> end of whatever is doing the redirect (especially with Alexei's work 

There are use cases where they may make sense, but this is not one.

> on linking) and from cls_bpf 🤷‍♂️
> 

cls_bpf is tc based == skb, no? I want to handle any packet, regardless
of how it arrived at the device's xmit function.

Powered by blists - more mailing lists