On Tue, Feb 28, 2017 at 12:43 PM, Willem de Bruijn
[off-list ref] wrote:
On Tue, Feb 28, 2017 at 2:46 PM, Andy Lutomirski [off-list ref] wrote:
quoted
On Mon, Feb 27, 2017 at 10:57 AM, Michael Kerrisk
[off-list ref] wrote:
quoted
[CC += linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org]
Hi Willem
quoted
quoted
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.
Operations that read or write payload, such as this crypto example,
but also ebpf in tc or iptables, for instance, demand a deep copy using
skb_copy_ubufs before the operation.
This blacklist approach requires caution, but these paths should be
few and countable. It is not possible to predict at the socket layer
whether a packet will encounter any such operation, so white-listing
a subset of end-to-end paths is not practical.
How about hardware that malfunctions if the packet changes out from
under it? A whitelist seems quite a bit safer.
--Andy
From: Andy Lutomirski <luto@amacapital.net>
Date: Tue, 28 Feb 2017 13:06:49 -0800
On Tue, Feb 28, 2017 at 12:43 PM, Willem de Bruijn
[off-list ref] wrote:
quoted
On Tue, Feb 28, 2017 at 2:46 PM, Andy Lutomirski [off-list ref] wrote:
quoted
On Mon, Feb 27, 2017 at 10:57 AM, Michael Kerrisk
[off-list ref] wrote:
quoted
[CC += linux-api@vger.kernel.org]
Hi Willem
quoted
quoted
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.
Operations that read or write payload, such as this crypto example,
but also ebpf in tc or iptables, for instance, demand a deep copy using
skb_copy_ubufs before the operation.
This blacklist approach requires caution, but these paths should be
few and countable. It is not possible to predict at the socket layer
whether a packet will encounter any such operation, so white-listing
a subset of end-to-end paths is not practical.
How about hardware that malfunctions if the packet changes out from
under it? A whitelist seems quite a bit safer.
These device are already choking, because as I stated this can already
be done via sendfile().
Networking card wise this isn't an issue, chips bring the entire packet
into their FIFO, compute checksums on the fly mid-stream, and then write
the 16-bit checksum field before starting to write the packet onto the
wire.
I think this is completely a non-issue, and we thought about this right
from the start when sendfile() support was added nearly two decades ago.
If network cards from back then didn't crap out in this situation I
think the ones out there now are probably ok.
On Tue, 2017-02-28 at 22:28 -0500, David Miller wrote:
These device are already choking, because as I stated this can already
be done via sendfile().
Networking card wise this isn't an issue, chips bring the entire packet
into their FIFO, compute checksums on the fly mid-stream, and then write
the 16-bit checksum field before starting to write the packet onto the
wire.
I think this is completely a non-issue, and we thought about this right
from the start when sendfile() support was added nearly two decades ago.
If network cards from back then didn't crap out in this situation I
think the ones out there now are probably ok.
Well, we had to fix one issue with GSO fall back about 4 years ago.
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=cef401de7be8c4e155c6746bfccf721a4fa5fab9
So extra scrutiny would be nice.
Zero copy is incredibly hard to get right.
On Tue, Feb 28, 2017 at 7:28 PM, David Miller [off-list ref] wrote:
From: Andy Lutomirski <luto@amacapital.net>
Date: Tue, 28 Feb 2017 13:06:49 -0800
quoted
On Tue, Feb 28, 2017 at 12:43 PM, Willem de Bruijn
[off-list ref] wrote:
quoted
On Tue, Feb 28, 2017 at 2:46 PM, Andy Lutomirski [off-list ref] wrote:
quoted
On Mon, Feb 27, 2017 at 10:57 AM, Michael Kerrisk
[off-list ref] wrote:
quoted
[CC += linux-api@vger.kernel.org]
Hi Willem
quoted
quoted
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.
Operations that read or write payload, such as this crypto example,
but also ebpf in tc or iptables, for instance, demand a deep copy using
skb_copy_ubufs before the operation.
This blacklist approach requires caution, but these paths should be
few and countable. It is not possible to predict at the socket layer
whether a packet will encounter any such operation, so white-listing
a subset of end-to-end paths is not practical.
How about hardware that malfunctions if the packet changes out from
under it? A whitelist seems quite a bit safer.
These device are already choking, because as I stated this can already
be done via sendfile().
Networking card wise this isn't an issue, chips bring the entire packet
into their FIFO, compute checksums on the fly mid-stream, and then write
the 16-bit checksum field before starting to write the packet onto the
wire.
I think this is completely a non-issue, and we thought about this right
from the start when sendfile() support was added nearly two decades ago.
If network cards from back then didn't crap out in this situation I
think the ones out there now are probably ok.
Fair enough.