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: <20190223114343.5813f18a@carbon>
Date:   Sat, 23 Feb 2019 11:43:43 +0100
From:   Jesper Dangaard Brouer <brouer@...hat.com>
To:     Jakub Kicinski <jakub.kicinski@...ronome.com>
Cc:     Toke Høiland-Jørgensen <toke@...hat.com>,
        David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
        Daniel Borkmann <daniel@...earbox.net>,
        Alexei Starovoitov <ast@...nel.org>, brouer@...hat.com
Subject: Re: [PATCH net-next 1/2] xdp: Always use a devmap for XDP_REDIRECT
 to a device


On Fri, 22 Feb 2019 13:37:34 -0800 Jakub Kicinski <jakub.kicinski@...ronome.com> wrote:

> On Fri, 22 Feb 2019 11:13:50 +0100, Toke Høiland-Jørgensen wrote:
> > Jakub Kicinski <jakub.kicinski@...ronome.com> writes:  
> > > On Thu, 21 Feb 2019 12:56:54 +0100, Toke Høiland-Jørgensen wrote:    
[...]
> > >
> > > BPF programs don't obey by netns boundaries.  The fact the program is
> > > verified in one ns doesn't mean this is the only ns it will be used in :(
> > > Meaning if any program is using the redirect map you may need a secret
> > > map in every ns.. no?    
> > 
> > Ah, yes, good point. Totally didn't think about the fact that load and
> > attach are decoupled. Hmm, guess I'll just have to move the call to
> > alloc_default_map() to the point where the program is attached to an
> > interface, then...  
> 
> Possibly.. and you also need to handle the case where interface with a
> program attached is moved, no?

True, we need to handle if e.g. a veth gets an XDP program attached and
then is moved into a network namespace (as I've already explained to
Toke in a meeting).

I'm still not sure how to handle this...

-- 
Best regards,
  Jesper Dangaard Brouer
  MSc.CS, Principal Kernel Engineer at Red Hat
  LinkedIn: http://www.linkedin.com/in/brouer

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ