[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALCETrU3tohXaoOTMi8J4FdTggGhvauHt12KyLFV=Q0FjiDNbg@mail.gmail.com>
Date: Tue, 28 Feb 2017 11:46:23 -0800
From: Andy Lutomirski <luto@...capital.net>
To: Michael Kerrisk <mtk.manpages@...il.com>
Cc: Willem de Bruijn <willemdebruijn.kernel@...il.com>,
netdev <netdev@...r.kernel.org>,
Willem de Bruijn <willemb@...gle.com>,
Linux API <linux-api@...r.kernel.org>
Subject: Re: [PATCH RFC v2 00/12] socket sendmsg MSG_ZEROCOPY
On Mon, Feb 27, 2017 at 10:57 AM, Michael Kerrisk
<mtk.manpages@...il.com> wrote:
> [CC += linux-api@...r.kernel.org]
>
> Hi Willem
>
>> On a send call with MSG_ZEROCOPY, the kernel pins the user pages and
>> creates skbuff fragments directly from these pages. On tx completion,
>> it notifies the socket owner that it is safe to modify memory by
>> queuing a completion notification onto the socket error queue.
What happens if the user writes to the pages while it's not safe?
How about if you're writing to an interface or a route that has crypto
involved and a malicious user can make the data change in the middle
of a crypto operation, thus perhaps leaking the entire key? (I
wouldn't be at all surprised if a lot of provably secure AEAD
constructions are entirely compromised if an attacker can get the
ciphertext and tag computed from a message that changed during the
computation.
I can see this working if you have a special type of skb that
indicates that the data might be concurrently written and have all the
normal skb APIs (including, especially, anything that clones it) make
a copy first.
--Andy
Powered by blists - more mailing lists