netdev - Re: [PATCH bpf] Revert "xdp: add NULL pointer check in __xdp

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: <5d07c5ce-2dea-7ab2-f5cf-7ed22d5da783@iogearbox.net>
Date:   Fri, 10 Aug 2018 16:10:02 +0200
From:   Daniel Borkmann <daniel@...earbox.net>
To:     Björn Töpel <bjorn.topel@...il.com>,
        ast@...com, netdev@...r.kernel.org, ap420073@...il.com,
        brouer@...hat.com
Cc:     Björn Töpel <bjorn.topel@...el.com>,
        magnus.karlsson@...el.com, magnus.karlsson@...il.com, kafai@...com
Subject: Re: [PATCH bpf] Revert "xdp: add NULL pointer check in
 __xdp_return()"

On 08/10/2018 11:28 AM, Björn Töpel wrote:
> From: Björn Töpel <bjorn.topel@...el.com>
> 
> This reverts commit 36e0f12bbfd3016f495904b35e41c5711707509f.
> 
> The reverted commit adds a WARN to check against NULL entries in the
> mem_id_ht rhashtable. Any kernel path implementing the XDP (generic or
> driver) fast path is required to make a paired
> xdp_rxq_info_reg/xdp_rxq_info_unreg call for proper function. In
> addition, a driver using a different allocation scheme than the
> default MEM_TYPE_PAGE_SHARED is required to additionally call
> xdp_rxq_info_reg_mem_model.
> 
> For MEM_TYPE_ZERO_COPY, an xdp_rxq_info_reg_mem_model call ensures
> that the mem_id_ht rhashtable has a properly inserted allocator id. If
> not, this would be a driver bug. A NULL pointer kernel OOPS is
> preferred to the WARN.
> 
> Suggested-by: Jesper Dangaard Brouer <brouer@...hat.com>
> Signed-off-by: Björn Töpel <bjorn.topel@...el.com>

Given the last bpf pr went out yesterday night, I've applied this to
bpf-next (worst case we can just route it via stable), thanks!