netdev - Multicast/Broadcast enhancement: SKB read-only with copy-on-write

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-next>] [day] [month] [year] [list]

Date:	Mon, 4 Mar 2013 10:29:22 -0500
From:	Yannick Koehler <yannick@...hler.name>
To:	netdev@...r.kernel.org
Subject: Multicast/Broadcast enhancement: SKB read-only with copy-on-write

Hi,

  Recently I was working into the kernel area where the code handle
broadcast/multicast in bridge logical interface for example.  It seems
today inevitable that when we flood, the bridge code has to duplicate
the full SKB, metadata as well as data, in order to transmit to each
link under it.  I was wondering if there was way for the SKB system to
support copy-on-write, such that, from a starting point, the SKB would
be "frozen" into a read-only mode and then if someone wants to modify
the SKB metadata/data it is done in a way to preserve the original SKB
memory, as to ensure that after the SKB has been transmitted over that
particular link, it can also be used without a full memory copy to be
sent to subsequent link, simultaneously on multi-core/mutli-interface
system.

  I am wondering at what level such work would be consider, is it
relatively easy, does Linux have anything like that, is it major work,
since pretty much everyone expect SKB data to be writable (like
skb_may_pull could be used to obtain a specific client SKB version
area).  It would probably require a new field in the SKB to indicate
that this is a read-only/copy-on-write version of a specific "original
SKB".

  Anyway, just wanted some thoughts/opinions on the topic regarding
the scale of such a change.

--
Yannick Koehler
--
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