[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20141014.220111.179628329028952302.davem@davemloft.net>
Date: Tue, 14 Oct 2014 22:01:11 -0400 (EDT)
From: David Miller <davem@...emloft.net>
To: luto@...capital.net
Cc: torvalds@...ux-foundation.org, kaber@...sh.net,
netdev@...r.kernel.org, tgraf@...g.ch
Subject: Re: Netlink mmap tx security?
From: Andy Lutomirski <luto@...capital.net>
Date: Tue, 14 Oct 2014 15:16:46 -0700
> It's at least remotely possible that there's something that assumes
> that assumes that the availability of NETLINK_RX_RING implies
> NETLINK_TX_RING, which would be unfortunate.
I already found one such case, nlmon :-/
It also reminds me that I'll have to update
Documentation/networking/netlink_mmap.txt
Thomas, the context is that we have to remove NETLINK_TX_RING support
(there is absolutely no way whatsoever to reliably keep some thread of
control from modifying the underlying pages while we parse and
validate the netlink request).
I'd like to be able to do so while retaining NETLINK_RX_RING because
that works fine and is great for monitoring when the rate of events
is high.
But I already have found userland pieces of code, like nlmon, which
assume that if one is present then both must be present.
I really think this means I'll have to remove all of the netlink
mmap() support in order to prevent from breaking applications. :(
The other option is to keep NETLINK_TX_RING, but copy the data into
a kernel side buffer before acting upon it.
--
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
Powered by blists - more mailing lists