linux-kernel - Re: vhost-net

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: <9d64ef0e-5e92-98f7-4620-c50561dad3a8@norrbonn.se>
Date:   Thu, 19 Jan 2023 14:12:58 +0100
From:   Jonas Bonn <jonas@...rbonn.se>
To:     Jason Wang <jasowang@...hat.com>
Cc:     "Michael S. Tsirkin" <mst@...hat.com>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: vhost-net

Hi Jason,

Thanks for your feedback.

On 17/01/2023 05:26, Jason Wang wrote:
> On Mon, Jan 16, 2023 at 4:59 PM Jonas Bonn <jonas@...rbonn.se> wrote:
>>
>> For an IFF_TUN device, should vhost-net not be adding an implicit
>> ethernet header in _build_xdp()?
> 
> Probably.
> 
> Actually, this makes me think that we should disable XDP for TUN?

After playing around with this for a week, I agree.  It appears that as 
soon as the XDP paths come into play there are requirements on having 
valid ethernet headers in place; the TUN interface doesn't even have a 
MAC address to validate against so packets in the TCP paths get dropped. 
  UDP packet validation apparently only cares about the ethernet "proto" 
field so these can be made to go through with less rigorous ethernet 
addressing.

That said, when the XDP path is bypassed, the TUN device works fine with 
vhost-net.

> 
>> Can this be done without backward
>> compatibility implications?
>>
> 
> The path is used by vhost-net only, so I think we are fine.
> 
> Patch is more than welcomed.

I'll try to put something together.

/Jonas