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: <20161031.145734.1243544464767231445.davem@davemloft.net>
Date:   Mon, 31 Oct 2016 14:57:34 -0400 (EDT)
From:   David Miller <davem@...emloft.net>
To:     Yuval.Mintz@...ium.com
Cc:     netdev@...r.kernel.org
Subject: Re: XDP question - how much can BPF change in xdp_buff?

From: "Mintz, Yuval" <Yuval.Mintz@...ium.com>
Date: Mon, 31 Oct 2016 18:31:30 +0000

> So I've [finally] started looking into implementing XDP
> for qede, and there's one thing I feel like I'm missing in
> regard to XDP_TX - what's the guarantee/requirement
> that the bpf program isn't going to transmute some fields
> of the rx packet in a way that would prevent the forwarding?
> 
> E.g., can a BPF change the TCP payload of an incoming packet
> without correcting its TCP checksum, and then expect the
> driver to transmit it [via XDP_TX]? If not, how is this enforced [if at all]?
> 
> [Looked at samples/bpf/xdp2_kern.c which manipulates the
> UDP header; so I'm not certain what prevents it from doing
> the same when checksum modifications would be required]

My understanding is that the eBPF program would be responsible
for updating the checksum if it mangles the packet in such a
way that such a fixup would be required.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ