# Re: \[PATCH RFC v2 00/12\] socket sendmsg MSG\_ZEROCOPY - List: linux-api - 4 messages, 4 authors - Page: https://ratatoskr.run/linux-api/2017/02/11046262/t ## Re: \[PATCH RFC v2 00/12\] socket sendmsg MSG\_ZEROCOPY - From: Andy Lutomirski \ - Date: 2017-02-28 21:06:49 - Message: https://ratatoskr.run/linux-api/2017/02/11046262.md ```text On Tue, Feb 28, 2017 at 12:43 PM, Willem de Bruijn [ref] wrote: > On Tue, Feb 28, 2017 at 2:46 PM, Andy Lutomirski [ref] wrote: >> On Mon, Feb 27, 2017 at 10:57 AM, Michael Kerrisk >> [ref] wrote: >>> [CC += linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.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. > > 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 ``` ## Re: \[PATCH RFC v2 00/12\] socket sendmsg MSG\_ZEROCOPY - From: David Miller \ - Date: 2017-03-01 03:29:43 - Message: https://ratatoskr.run/linux-api/2017/03/11046294.md ```text From: Andy Lutomirski Date: Tue, 28 Feb 2017 13:06:49 -0800 > On Tue, Feb 28, 2017 at 12:43 PM, Willem de Bruijn > [ref] wrote: >> On Tue, Feb 28, 2017 at 2:46 PM, Andy Lutomirski [ref] wrote: >>> On Mon, Feb 27, 2017 at 10:57 AM, Michael Kerrisk >>> [ref] wrote: >>>> [CC += linux-api@vger.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. >> >> 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. ``` ## Re: \[PATCH RFC v2 00/12\] socket sendmsg MSG\_ZEROCOPY - From: Eric Dumazet \ - Date: 2017-03-01 03:43:14 - Message: https://ratatoskr.run/linux-api/2017/03/11046295.md ```text 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. ``` ## Re: \[PATCH RFC v2 00/12\] socket sendmsg MSG\_ZEROCOPY - From: Andy Lutomirski \ - Date: 2017-03-02 19:36:49 - Message: https://ratatoskr.run/linux-api/2017/03/11046392.md ```text On Tue, Feb 28, 2017 at 7:28 PM, David Miller [ref] wrote: > From: Andy Lutomirski > Date: Tue, 28 Feb 2017 13:06:49 -0800 > >> On Tue, Feb 28, 2017 at 12:43 PM, Willem de Bruijn >> [ref] wrote: >>> On Tue, Feb 28, 2017 at 2:46 PM, Andy Lutomirski [ref] wrote: >>>> On Mon, Feb 27, 2017 at 10:57 AM, Michael Kerrisk >>>> [ref] wrote: >>>>> [CC += linux-api@vger.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. >>> >>> 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. ```