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]
Date: Mon, 18 Mar 2024 12:43:16 +0100
From: Mark <mark@...suba.nl>
To: Ratheesh Kannoth <rkannoth@...vell.com>
Cc: "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
 Hans de Goede <hdegoede@...hat.com>,
 Eric Dumazet <edumazet@...gle.com>,
 Jakub Kicinski <kuba@...nel.org>,
 Breno Leitao <leitao@...ian.org>,
 Ingo Molnar <mingo@...hat.com>,
 "David S. Miller" <davem@...emloft.net>,
 Paolo Abeni <pabeni@...hat.com>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [EXTERNAL] [PATCH] netpoll: support sending over raw IP
 interfaces


Hi Ratheesh,

> Op 14 mrt 6 Reiwa, om 03:46 heeft Ratheesh Kannoth <rkannoth@...vell.com> het volgende geschreven:
> 
>> From: Mark <mark@...suba.nl>
>> […]
> 
> Hmm.  That is not my question.   Let me explain it in detail. Netconsole is using netpoll_send_udp() to encapsulate the msg over 
> UDP/IP/ MAC headers. Job well done. Now it calls netdev->ops->ndo_start_xmit(skb, dev).  If your driver is well aware that you can
> Transmit only from network header, why don’t you dma map from network header ?  

The rest of the network subsystem seems to not add a header to skbs submitted
to netdev->ops->ndo_start_xmit() at all, which makes sense considering
netdev->header_ops is either NULL or no-op for these devices.

Following this line of reasoning, from API perspective it made more sense
to me for netpoll to not submit ‘bogus’ skbs that are out-of-line with what
the rest of the network subsystem does to ndo_start_xmit() to begin with.
It really depends on the API guarantees we want to have for netdev,
but personally I'm wary of introducing an allowance for bogus headers.

Additionally from a practical perspective, this would require changing almost
every, if not every, IP interface driver. I took a look at the WireGuard
driver to see what it would entail, and from my limited experience with the
networking code it seems like there's some quite annoying interactions with
e.g. GSO which would make driver-side handling of such packets quite a bit
more complex.

So from my perspective, fixing this in netpoll is both the more API-correct
change and introduces the least amount of additional complexity.

> […]

Thanks and regards,
Mark

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ