[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20180305.164008.2006986778756330199.davem@davemloft.net>
Date: Mon, 05 Mar 2018 16:40:08 -0500 (EST)
From: David Miller <davem@...emloft.net>
To: john.fastabend@...il.com
Cc: ast@...nel.org, daniel@...earbox.net, netdev@...r.kernel.org,
davejwatson@...com
Subject: Re: [bpf-next PATCH 05/16] bpf: create tcp_bpf_ulp allowing BPF to
monitor socket TX/RX data
From: John Fastabend <john.fastabend@...il.com>
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.
Powered by blists - more mailing lists