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. --Andy -- 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
