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:   Fri, 24 Jan 2020 07:21:28 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     David Ahern <dsahern@...il.com>
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 Thu, 23 Jan 2020 14:33:42 -0700, David Ahern wrote:
> On 1/23/20 4:35 AM, Toke Høiland-Jørgensen wrote:
> > David Ahern <dsahern@...nel.org> writes:
> >> From: David Ahern <dahern@...italocean.com>
> >>
> >> Add IFLA_XDP_EGRESS to if_link.h uapi to handle an XDP program attached
> >> to the egress path of a device. Add rtnl_xdp_egress_fill and helpers as
> >> the egress counterpart to the existing rtnl_xdp_fill. The expectation
> >> is that going forward egress path will acquire the various levels of
> >> attach - generic, driver and hardware.  
> > 
> > How would a 'hardware' attach work for this? As I said in my reply to
> > the previous patch, isn't this explicitly for emulating XDP on the other
> > end of a point-to-point link? How would that work with offloaded
> > programs?
> 
> Nothing about this patch set is limited to point-to-point links.

I struggle to understand of what the expected semantics of this new
hook are. Is this going to be run on all frames sent to the device
from the stack? All frames from the stack and from XDP_REDIRECT?

A little hard to figure out the semantics when we start from a funky
device like tun :S

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ