From: Andy Lutomirski <luto@xxxxxxxxxxxxxx> Date: Tue, 28 Feb 2017 13:06:49 -0800 > On Tue, Feb 28, 2017 at 12:43 PM, Willem de Bruijn > <willemdebruijn.kernel@xxxxxxxxx> wrote: >> On Tue, Feb 28, 2017 at 2:46 PM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: >>> On Mon, Feb 27, 2017 at 10:57 AM, Michael Kerrisk >>> <mtk.manpages@xxxxxxxxx> wrote: >>>> [CC += linux-api@xxxxxxxxxxxxxxx] >>>> >>>> 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. >> >> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
