From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Lutomirski Subject: Re: Netlink mmap tx security? Date: Tue, 14 Oct 2014 15:16:46 -0700 Message-ID: References: <20141014.151949.1967601568480255495.davem@davemloft.net> <20141014.160056.2113064815910782529.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Cc: Linus Torvalds , Patrick McHardy , Network Development To: David Miller Return-path: Received: from mail-la0-f52.google.com ([209.85.215.52]:35749 "EHLO mail-la0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754621AbaJNWRI (ORCPT ); Tue, 14 Oct 2014 18:17:08 -0400 Received: by mail-la0-f52.google.com with SMTP id hz20so13643lab.39 for ; Tue, 14 Oct 2014 15:17:06 -0700 (PDT) In-Reply-To: <20141014.160056.2113064815910782529.davem@davemloft.net> Sender: netdev-owner@vger.kernel.org List-ID: On Tue, Oct 14, 2014 at 1:00 PM, David Miller wrote: > From: Andy Lutomirski > Date: Tue, 14 Oct 2014 12:33:43 -0700 > >> For full honesty, there is now the machinery developed for memfd >> sealing, but I can't imagine that this is ever faster than just >> copying the buffer. > > I don't have much motivation to even check if it's a worthwhile > pursuit at this point. > > Someone who wants to can :-) > >> I think that the NETLINK_SKB_TX declaration in include/linux/netlink.h >> should probably go, too. And there's the last parameter to >> netlink_set_ring, too, and possibly even the nlk->tx_ring struct >> itself. > > Agreed on all counts, here is the new patch: > > ==================== > [PATCH] netlink: Remove TX mmap support. > > There is no reasonable manner in which to absolutely make sure that another > thread of control cannot write to the pages in the mmap()'d area and thus > make sure that netlink messages do not change underneath us after we've > performed verifications. > > Reported-by: Andy Lutomirski > Signed-off-by: David S. Miller Looks sensible to me, but I have no idea how to test it. 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. --Andy