netdev - Re: [1/2 bpf-next] bpf: expose net_device from xdp for metadata

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]

Message-ID: <20221116114633.6a297935@kernel.org>
Date:   Wed, 16 Nov 2022 11:46:33 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     John Fastabend <john.fastabend@...il.com>
Cc:     Yonghong Song <yhs@...a.com>, hawk@...nel.org,
        daniel@...earbox.net, davem@...emloft.net, ast@...nel.org,
        netdev@...r.kernel.org, bpf@...r.kernel.org, sdf@...gle.com
Subject: Re: [1/2 bpf-next] bpf: expose net_device from xdp for metadata

On Mon, 14 Nov 2022 10:23:00 -0800 John Fastabend wrote:
> > > The other piece I would like to get out of the xdp ctx is the
> > > rx descriptor of the device. I want to use this to pull out info
> > > about the received buffer for debug mostly, but could also grab
> > > some fields that are useful for us to track. That we can likely
> > > do this,
> > > 
> > >    ctx->rxdesc  
> > 
> > I think it is possible. Adding rxdesc to xdp_buff as
> >      unsigned char *rxdesc;
> > or
> >      void *rxdesc;

We should avoid having to add fields to structures just to expose 
them to BPF. Would the approach that Stan uses not work here?
Having the driver place the desc pointer in a well known location
on the stack and kfunc or some other magic resolve it?
 
> > and using bpf_get_kern_btf_id(kctx->rxdesc, expected_btf_id)
> > to get a btf id for rxdesc. Here we assume there is
> > a struct available for rxdesc in vmlinux.h.
> > Then you can trace through rxdesc with direct memory
> > access.  
> 
> The trickest part here is that the rxdesc btf_id depends on 
> what device we are attached to. So would need something to
> resolve the btf_id from attached device.

Right, driver needs to get involved one way or another, so it can
return "how to get to the descriptor given a xdp_buff pointer" 
as well as the btf_id or dynptr params.

(Sorry, I'm only catching up with the xdp hw field discussions
now so this may have already been discussed elsewhere..)