netdev - Re: [PATCH] Packet socket: mmapped IO: PACKET_TX

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: <20081106080316.GA32337@ioremap.net>
Date:	Thu, 6 Nov 2008 11:03:16 +0300
From:	Evgeniy Polyakov <zbr@...emap.net>
To:	"Lovich, Vitali" <vlovich@...lcomm.com>
Cc:	Johann Baudy <johaahn@...il.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH] Packet socket: mmapped IO: PACKET_TX_RING

Hi Vitali.

On Wed, Nov 05, 2008 at 04:47:03PM -0800, Lovich, Vitali (vlovich@...lcomm.com) wrote:
> In either case, the skb given to the destructor will still have the correct values for fragments we specified.  Of course, this is based on 2 assumptions:
> 
> 1.  Nothing further down the line won't add fragments, thereby overwriting frags[0]
> 2.  No-one writes to frags[0].page & frags[0].page_offset
> 
> 1 is reasonable because since the only reason we would be linearizing in the first place is if the device doesn't support scatter/gather, so it would be strange for something down the line to add more fragments that would have to be linearized anyways.
> 
> 2 is reasonable since it would only make sense if something down the line used this as a temporary variable storage, which again should be unlikely.

What if skb was queued in hardware or qdisk and userspace rewrites
mapped page placed in fraglist?

> Another approach may be to store it in the cb as we had done so originally, except with skb_clone to ensure no other layers overwrite it, although I'm not 100% sure of the implications of skb_clone has for things like the cb & users fields and kfree_skb.

It is not allowed to store something in cb block which is intended to
live while skb is processed on different layers. In this particular case
qdisk engine will overwrite skb's cb.

-- 
	Evgeniy Polyakov
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html