Back in 2014, patches "net: sched: af_packet support for direct ring
access" were rejected since there was no memory protection performed by
any part of the system.
The point of the patchset was
to split off a set of driver queues
from the driver and map the queues into user space via mmap. This
allows the queues to be directly manipulated from user space. For
raw packet interface this removes any overhead from the kernel network
stack.
In other words this was proposed to help people using userspace drivers -
they don't really need them to be in full control of their devices. Only
data path operations need to avoid system call overhead, all setup is
better off managed by the kernel (maybe they should stop using userspace
drivers, but that's a different discussion).
Unfortunately the patches were insecure: as all dma memory accesses by the
same device are tagged with the same source (bus/device/function) the
iommu can not differentiate between kernel and userspace queues and so
can not protect us from a malicious userspace. So from security POV
this is not much better than userspace banging hardware registers
directly really.
However, there actually exists a way to attach an extra tag
to each pci express transaction, and that's with PASID support
which has been supported in the kernel for a while now.
So all we need is a NIC that will allow the kernel to attach a PASID tag
to queues that are given to userspace, and the patches could then be
made safe for this NIC by using the IOMMU for protection.
GPUs commonly support PASIDs and utilize this for security more or less
exactly like this, but I do not think any NICs do, so far.
Why not?
Could this be something that's easy to add to existing/future hardware?
Maybe with a firmware update? What we need is just ability to specify
for each queue which PASID to use when doing DMA to send/receive
packets.
Not working for a hardware vendor, I'd love to hear from people who are.
Thanks,
--
MST
