netdev - Re: [PATCH bpf-next v4 01/15] xsk: fix xsk_umem_xdp_frame

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: <CAJ+HfNg73Wfq0ODX4kY396yyNQ-zAn1szssqqQNu4+DLbdSb2A@mail.gmail.com>
Date:   Thu, 21 May 2020 20:06:15 +0200
From:   Björn Töpel <bjorn.topel@...il.com>
To:     Jesper Dangaard Brouer <brouer@...hat.com>
Cc:     Björn Töpel <bjorn.topel@...el.com>,
        Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        David Miller <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Jesper Dangaard Brouer <hawk@...nel.org>,
        John Fastabend <john.fastabend@...il.com>,
        Netdev <netdev@...r.kernel.org>, bpf <bpf@...r.kernel.org>,
        "Karlsson, Magnus" <magnus.karlsson@...el.com>,
        Jonathan Lemon <jonathan.lemon@...il.com>,
        Jeff Kirsher <jeffrey.t.kirsher@...el.com>,
        Maxim Mikityanskiy <maximmi@...lanox.com>,
        "Fijalkowski, Maciej" <maciej.fijalkowski@...el.com>
Subject: Re: [PATCH bpf-next v4 01/15] xsk: fix xsk_umem_xdp_frame_sz()

On Thu, 21 May 2020 at 06:30, Jesper Dangaard Brouer <brouer@...hat.com> wrote:
>
> On Wed, 20 May 2020 16:34:05 +0200
> Björn Töpel <bjorn.topel@...el.com> wrote:
>
> > On 2020-05-20 15:18, Jesper Dangaard Brouer wrote:
> > > On Wed, 20 May 2020 11:47:28 +0200
> > > Björn Töpel <bjorn.topel@...il.com> wrote:
> > >
> > >> From: Björn Töpel <bjorn.topel@...el.com>
> > >>
> > >> Calculating the "data_hard_end" for an XDP buffer coming from AF_XDP
> > >> zero-copy mode, the return value of xsk_umem_xdp_frame_sz() is added
> > >> to "data_hard_start".
> > >>
> > >> Currently, the chunk size of the UMEM is returned by
> > >> xsk_umem_xdp_frame_sz(). This is not correct, if the fixed UMEM
> > >> headroom is non-zero. Fix this by returning the chunk_size without the
> > >> UMEM headroom.
> > >>
> > >> Fixes: 2a637c5b1aaf ("xdp: For Intel AF_XDP drivers add XDP frame_sz")
> > >> Signed-off-by: Björn Töpel <bjorn.topel@...el.com>
> > >> ---
> > >>   include/net/xdp_sock.h | 2 +-
> > >>   1 file changed, 1 insertion(+), 1 deletion(-)
> > >>
> > >> diff --git a/include/net/xdp_sock.h b/include/net/xdp_sock.h
> > >> index abd72de25fa4..6b1137ce1692 100644
> > >> --- a/include/net/xdp_sock.h
> > >> +++ b/include/net/xdp_sock.h
> > >> @@ -239,7 +239,7 @@ static inline u64 xsk_umem_adjust_offset(struct xdp_umem *umem, u64 address,
> > >>
> > >>   static inline u32 xsk_umem_xdp_frame_sz(struct xdp_umem *umem)
> > >>   {
> > >> -  return umem->chunk_size_nohr + umem->headroom;
> > >> +  return umem->chunk_size_nohr;
> > >
> > > Hmm, is this correct?
> > >
> > > As you write "xdp_data_hard_end" is calculated as an offset from
> > > xdp->data_hard_start pointer based on the frame_sz.  Will your
> > > xdp->data_hard_start + frame_sz point to packet end?
> > >
> >
> > Yes, I believe this is correct.
> >
> > Say that a user uses a chunk size of 2k, and a umem headroom of, say,
> > 64. This means that the kernel should (at least) leave 64B which the
> > kernel shouldn't touch.
> >
> > umem->headroom | XDP_PACKET_HEADROOM | packet |          |
> >                 ^                     ^        ^      ^   ^
> >                 a                     b        c      d   e
> >
> > a: data_hard_start
> > b: data
> > c: data_end
> > d: data_hard_end, (e - 320)
> > e: hardlimit of chunk, a + umem->chunk_size_nohr
> >
> > Prior this fix the umem->headroom was *included* in frame_sz.
>
> Thanks for the nice ascii art description. I can now see that you are
> right.   We should add this kind of documentation, perhaps as a comment
> in the code?
>

Definitely! I'd say both in code, and af_xdp.rst! I'll make a patch.
Thanks for the suggestion!

Cheers,
Björn