[bpf-next,v2,05/18] bpf: create tcp_bpf_ulp allowing BPF to monitor socket TX/RX data

From: John Fastabend <john.fastabend@gmail.com>

This implements a BPF ULP layer to allow policy enforcement and
monitoring at the socket layer. In order to support this a new
program type BPF_PROG_TYPE_SK_MSG is used to run the policy at
the sendmsg/sendpage hook. To attach the policy to sockets a
sockmap is used with a new program attach type BPF_SK_MSG_VERDICT.

Similar to previous sockmap usages when a sock is added to a
sockmap, via a map update, if the map contains a BPF_SK_MSG_VERDICT
program type attached then the BPF ULP layer is created on the
socket and the attached BPF_PROG_TYPE_SK_MSG program is run for
every msg in sendmsg case and page/offset in sendpage case.

BPF_PROG_TYPE_SK_MSG Semantics/API:

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. The kernel space buffers are stored in a
scatterlist object where each element is a kernel memory buffer.
Some effort is made to coalesce data from the sendmsg call here.
For example a sendmsg call with many one byte iov entries will
likely be pushed into a single entry. The BPF program is run with
data pointers (start/end) pointing to the first sg element.

In the sendpage case data is not copied. We opt not to copy the
data by default here, because the BPF infrastructure does not
know what bytes will be needed nor when they will be needed. So
copying all bytes may be wasteful. Because of this the initial
start/end data pointers are (0,0). Meaning no data can be read or
written. This avoids reading data that may be modified by the
user. A new helper is added later in this series if reading and
writing the data is needed. The helper call will do a copy by
default so that the page is exclusively owned by the BPF call.

The verdict from the BPF_PROG_TYPE_SK_MSG applies to the entire msg
in the sendmsg() case and the entire page/offset in the sendpage case.
This avoids ambiguity on how to handle mixed return codes in the
sendmsg case. Again a helper is added later in the series if
a verdict needs to apply to multiple system calls and/or only
a subpart of the currently being processed message.

The helper msg_redirect_map() can be used to select the socket to
send the data on. This is used similar to existing redirect use
cases. This allows policy to redirect msgs.

Pseudo code simple example:

The basic logic to attach a program to a socket is as follows,

  // load the programs
  bpf_prog_load(SOCKMAP_TCP_MSG_PROG, BPF_PROG_TYPE_SK_MSG,
		&obj, &msg_prog);

  // lookup the sockmap
  bpf_map_msg = bpf_object__find_map_by_name(obj, "my_sock_map");

  // get fd for sockmap
  map_fd_msg = bpf_map__fd(bpf_map_msg);

  // attach program to sockmap
  bpf_prog_attach(msg_prog, map_fd_msg, BPF_SK_MSG_VERDICT, 0);

Adding sockets to the map is done in the normal way,

  // Add a socket 'fd' to sockmap at location 'i'
  bpf_map_update_elem(map_fd_msg, &i, fd, BPF_ANY);

After the above any socket attached to "my_sock_map", in this case
'fd', will run the BPF msg verdict program (msg_prog) on every
sendmsg and sendpage system call.

For a complete example see BPF selftests or sockmap samples.

Implementation notes:

It seemed the simplest, to me at least, to use a refcnt to ensure
psock is not lost across the sendmsg copy into the sg, the bpf program
running on the data in sg_data, and the final pass to the TCP stack.
Some performance testing may show a better method to do this and avoid
the refcnt cost, but for now use the simpler method.

Another item that will come after basic support is in place is
supporting MSG_MORE flag. At the moment we call sendpages even if
the MSG_MORE flag is set. An enhancement would be to collect the
pages into a larger scatterlist and pass down the stack. Notice that
bpf_tcp_sendmsg() could support this with some additional state saved
across sendmsg calls. I built the code to support this without having
to do refactoring work. Other features TBD include ZEROCOPY and the
TCP_RECV_QUEUE/TCP_NO_QUEUE support. This will follow initial series
shortly.

Future work could improve size limits on the scatterlist rings used
here. Currently, we use MAX_SKB_FRAGS simply because this was being
used already in the TLS case. Future work could extend the kernel sk
APIs to tune this depending on workload. This is a trade-off
between memory usage and throughput performance.

Signed-off-by: John Fastabend <john.fastabend@gmail.com>
---
 include/linux/bpf.h       |    1 
 include/linux/bpf_types.h |    1 
 include/linux/filter.h    |   17 +
 include/uapi/linux/bpf.h  |   28 ++
 kernel/bpf/sockmap.c      |  714 ++++++++++++++++++++++++++++++++++++++++++++-
 kernel/bpf/syscall.c      |   14 +
 kernel/bpf/verifier.c     |    5 
 net/core/filter.c         |  106 +++++++
 8 files changed, 863 insertions(+), 23 deletions(-)

Message ID	20180312192329.8039.75277.stgit@john-Precision-Tower-5810
State	Changes Requested, archived
Delegated to:	BPF Maintainers
Headers	show Return-Path: <netdev-owner@vger.kernel.org> X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=netdev-owner@vger.kernel.org; receiver=<UNKNOWN>) Authentication-Results: ozlabs.org; dmarc=fail (p=none dis=none) header.from=gmail.com Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 400SZh564nz9rxx for <patchwork-incoming@ozlabs.org>; Tue, 13 Mar 2018 06:23:40 +1100 (AEDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932274AbeCLTXh (ORCPT <rfc822;patchwork-incoming@ozlabs.org>); Mon, 12 Mar 2018 15:23:37 -0400 Received: from [75.106.27.153] ([75.106.27.153]:59490 "EHLO john-Precision-Tower-5810" rhost-flags-FAIL-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1751442AbeCLTXf (ORCPT <rfc822;netdev@vger.kernel.org>); Mon, 12 Mar 2018 15:23:35 -0400 Received: from [127.0.1.1] (localhost [127.0.0.1]) by john-Precision-Tower-5810 (Postfix) with ESMTP id A8E1BD442D0; Mon, 12 Mar 2018 12:23:29 -0700 (PDT) Subject: [bpf-next PATCH v2 05/18] bpf: create tcp_bpf_ulp allowing BPF to monitor socket TX/RX data From: John Fastabend <john.fastabend@gmail.com> To: davem@davemloft.net, ast@kernel.org, daniel@iogearbox.net, davejwatson@fb.com Cc: netdev@vger.kernel.org Date: Mon, 12 Mar 2018 12:23:29 -0700 Message-ID: <20180312192329.8039.75277.stgit@john-Precision-Tower-5810> In-Reply-To: <20180312192034.8039.70022.stgit@john-Precision-Tower-5810> References: <20180312192034.8039.70022.stgit@john-Precision-Tower-5810> User-Agent: StGit/0.17.1-dirty MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: <netdev.vger.kernel.org> X-Mailing-List: netdev@vger.kernel.org
Series	bpf,sockmap: sendmsg/sendfile ULP \| expand [bpf-next,v2,00/18] bpf,sockmap: sendmsg/sendfile ULP [bpf-next,v2,01/18] sock: make static tls function alloc_sg generic sock helper [bpf-next,v2,02/18] sockmap: convert refcnt to an atomic refcnt [bpf-next,v2,03/18] net: do_tcp_sendpages flag to avoid SKBTX_SHARED_FRAG [bpf-next,v2,04/18] net: generalize sk_alloc_sg to work with scatterlist rings [bpf-next,v2,05/18] bpf: create tcp_bpf_ulp allowing BPF to monitor socket TX/RX data [bpf-next,v2,06/18] bpf: sockmap, add bpf_msg_apply_bytes() helper [bpf-next,v2,07/18] bpf: sockmap, add msg_cork_bytes() helper [bpf-next,v2,08/18] bpf: sk_msg program helper bpf_sk_msg_pull_data [bpf-next,v2,09/18] bpf: add map tests for BPF_PROG_TYPE_SK_MSG [bpf-next,v2,10/18] bpf: add verifier tests for BPF_PROG_TYPE_SK_MSG [bpf-next,v2,11/18] bpf: sockmap sample, add option to attach SK_MSG program [bpf-next,v2,12/18] bpf: sockmap sample, add sendfile test [bpf-next,v2,13/18] bpf: sockmap sample, add data verification option [bpf-next,v2,14/18] bpf: sockmap, add sample option to test apply_bytes helper [bpf-next,v2,15/18] bpf: sockmap sample support for bpf_msg_cork_bytes() [bpf-next,v2,16/18] bpf: sockmap add SK_DROP tests [bpf-next,v2,17/18] bpf: sockmap sample test for bpf_msg_pull_data [bpf-next,v2,18/18] bpf: sockmap test script

[bpf-next,v2,05/18] bpf: create tcp_bpf_ulp allowing BPF to monitor socket TX/RX data

Commit Message

Comments

Patch