Message ID | 20200812163305.545447-1-leah.rumancik@gmail.com |
---|---|
Headers | show |
Series | block/bpf: add eBPF based block layer IO filtering | expand |
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