From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from shards.monkeyblade.net ([184.105.139.130]:58072 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932672AbeCEVkK (ORCPT ); Mon, 5 Mar 2018 16:40:10 -0500 Date: Mon, 05 Mar 2018 16:40:08 -0500 (EST) Message-Id: <20180305.164008.2006986778756330199.davem@davemloft.net> To: john.fastabend@gmail.com Cc: ast@kernel.org, daniel@iogearbox.net, netdev@vger.kernel.org, davejwatson@fb.com Subject: Re: [bpf-next PATCH 05/16] bpf: create tcp_bpf_ulp allowing BPF to monitor socket TX/RX data From: David Miller In-Reply-To: <20180305195122.6612.78322.stgit@john-Precision-Tower-5810> References: <20180305194616.6612.36343.stgit@john-Precision-Tower-5810> <20180305195122.6612.78322.stgit@john-Precision-Tower-5810> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: netdev-owner@vger.kernel.org List-ID: From: John Fastabend Date: Mon, 05 Mar 2018 11:51:22 -0800 > BPF_PROG_TYPE_SK_MSG supports only two return codes SK_PASS and > SK_DROP. Returning SK_DROP free's the copied data in the sendmsg > case and in the sendpage case leaves the data untouched. Both cases > return -EACESS to the user. Returning SK_PASS will allow the msg to > be sent. > > In the sendmsg case data is copied into kernel space buffers before > running the BPF program. In the sendpage case data is never copied. > The implication being users may change data after BPF programs run in > the sendpage case. (A flag will be added to always copy shortly > if the copy must always be performed). I don't see how the sendpage case can be right. The user can asynchronously change the page contents whenever they want, and if the BPF program runs on the old contents then the verdict is not for what actually ends up being sent on the socket. There is really no way to cheaply freeze the page contents other than to make a copy.