[RFC,0/4] block/bpf: add eBPF based block layer IO filtering

This patch series adds support for a new security mechanism to filter IO
in the block layer. With this patch series, the policy for IO filtering
can be programmed into an eBPF program which gets attached to the struct
gendisk. The filter can either drop or allow IO requests. It cannot modify
requests. We do not support splitting of IOs, and we do not support
filtering of IOs that bypass submit_bio (such as SG_IO, NVMe passthrough).
At Google, we use IO filtering to prevent accidental modification of data.

To facilitate this functionality, a new eBPF program type,
BPF_PROG_TYPE_IO_FILTER, and an associated attach type, BPF_BIO_SUBMIT,
have been added. The IO filter programs are invoked in submit_bio’s
make_generic_requests_check() which checks the program’s return value to
determine if the IO should be dropped or allowed. The program type can
also be used to monitor IO if the return value is always set to allow IO.

An example of an eBPF program to filter IO is provided below:

SEC("io_filter")
int run_filter(struct bpf_io_request *io_req)
{
	if ( <condition to block io> )
		return IO_BLOCK;
	else
		return IO_ALLOW;
}

This patchset was created as part of a summer internship project.

Leah Rumancik (4):
  bpf: add new prog_type BPF_PROG_TYPE_IO_FILTER
  bpf: add protect_gpt sample program
  bpf: add eBPF IO filter documentation
  bpf: add BPF_PROG_TYPE_LSM to bpftool name array

 Documentation/block/bpf_io_filter.rst         |  28 +++
 Documentation/block/index.rst                 |   1 +
 block/Makefile                                |   1 +
 block/blk-bpf-io-filter.c                     | 209 ++++++++++++++++++
 block/blk-bpf-io-filter.h                     |  16 ++
 block/blk-core.c                              |   6 +
 block/genhd.c                                 |   3 +
 include/linux/bpf_io_filter.h                 |  23 ++
 include/linux/bpf_types.h                     |   4 +
 include/linux/genhd.h                         |   4 +
 include/uapi/linux/bpf.h                      |  11 +
 init/Kconfig                                  |   8 +
 kernel/bpf/syscall.c                          |   9 +
 kernel/bpf/verifier.c                         |   1 +
 samples/bpf/Makefile                          |   3 +
 samples/bpf/protect_gpt_kern.c                |  21 ++
 samples/bpf/protect_gpt_user.c                | 133 +++++++++++
 tools/bpf/bpftool/feature.c                   |   2 +
 tools/bpf/bpftool/main.h                      |   3 +
 tools/include/uapi/linux/bpf.h                |  11 +
 tools/lib/bpf/libbpf.c                        |   2 +
 tools/lib/bpf/libbpf_probes.c                 |   1 +
 .../selftests/bpf/prog_tests/section_names.c  |   5 +
 23 files changed, 505 insertions(+)
 create mode 100644 Documentation/block/bpf_io_filter.rst
 create mode 100644 block/blk-bpf-io-filter.c
 create mode 100644 block/blk-bpf-io-filter.h
 create mode 100644 include/linux/bpf_io_filter.h
 create mode 100644 samples/bpf/protect_gpt_kern.c
 create mode 100644 samples/bpf/protect_gpt_user.c

On Wed, Aug 12, 2020 at 04:33:01PM +0000, Leah Rumancik wrote:
> This patch series adds support for a new security mechanism to filter IO
> in the block layer. With this patch series, the policy for IO filtering
> can be programmed into an eBPF program which gets attached to the struct
> gendisk. The filter can either drop or allow IO requests. It cannot modify
> requests. We do not support splitting of IOs, and we do not support
> filtering of IOs that bypass submit_bio (such as SG_IO, NVMe passthrough).

Which means it is not in any way useful for security, but just snake oil.

But even if it wasn't this is a way to big hammer with impact for to
the I/O fast path to be acceptable.

On Wed, Aug 12, 2020 at 04:33:01PM +0000, Leah Rumancik wrote:
> This patch series adds support for a new security mechanism to filter IO
> in the block layer. With this patch series, the policy for IO filtering
> can be programmed into an eBPF program which gets attached to the struct
> gendisk. The filter can either drop or allow IO requests. It cannot modify
> requests. We do not support splitting of IOs, and we do not support
> filtering of IOs that bypass submit_bio (such as SG_IO, NVMe passthrough).
> At Google, we use IO filtering to prevent accidental modification of data.

I understand both SCSI's Persistent Reservations and NVMe's Reservation
may prevent accidental modification of data on shared LUN/NS, but they may
not work in request level.

Could you explain a bit about some real use cases with this filter
mechanism? 


Thanks, 
Ming