Looking for way to program external MMU from userspace (or viable alternative)

Looking for way to program external MMU from userspace (or viable alternative)

[Simon Que]

Hi kernel community,

We have an external PCIe board with a custom coprocessor on it. We also
have code for a kernel driver for it. We have thought about upstreaming it,
but we realized that we can instead convert the driver to a userspace
driver using UIO.

However, there's one aspect of the system and driver that doesn't seem to
be covered by UIO. The external board has a MMU and a DMA interface that
allows it to copy data between the host system's RAM and its own internal
memory.

The current kernel driver code looks up the physical address of a page of
user-allocated memory by traversing the page table, and then writing the
physical address to the external MMU. If we were to move the driver to
userspace, this procedure would require exposing the physical address to
user space, which insecure and thus a no-go.

What possibilities are there for programming the MMU from a userspace
driver?

For reference, here is the existing kernel driver code -- start from
apex_driver.c.
https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/981313

Simon

Re: Looking for way to program external MMU from userspace (or viable alternative)

[Jerome Glisse]

On Tue, Apr 03, 2018 at 01:27:36AM +0000, Simon Que wrote:
> Hi kernel community,
> 
> We have an external PCIe board with a custom coprocessor on it. We also
> have code for a kernel driver for it. We have thought about upstreaming it,
> but we realized that we can instead convert the driver to a userspace
> driver using UIO.
> 
> However, there's one aspect of the system and driver that doesn't seem to
> be covered by UIO. The external board has a MMU and a DMA interface that
> allows it to copy data between the host system's RAM and its own internal
> memory.
> 
> The current kernel driver code looks up the physical address of a page of
> user-allocated memory by traversing the page table, and then writing the
> physical address to the external MMU. If we were to move the driver to
> userspace, this procedure would require exposing the physical address to
> user space, which insecure and thus a no-go.
> 
> What possibilities are there for programming the MMU from a userspace
> driver?
> 
> For reference, here is the existing kernel driver code -- start from
> apex_driver.c.
> https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/981313

AFAIK not do-able and not something you want to do. UIO is for very
very basic device, no MMU or DMA. Allowing any such thing from user
space is wide opening the door to random DMA exploitation especialy
if there is no IOMMU.

Cheers,
Jérôme

Re: Looking for way to program external MMU from userspace (or viable alternative)

[Alan Cox]

> The current kernel driver code looks up the physical address of a page of
> user-allocated memory by traversing the page table, and then writing the
> physical address to the external MMU. If we were to move the driver to
> userspace, this procedure would require exposing the physical address to
> user space, which insecure and thus a no-go.
> 
> What possibilities are there for programming the MMU from a userspace
> driver?

If you want to be secure none.

That's not to say you can't keep most of the code in user space but
you'll need the DMA and MMU manager to be kernel side because you have to
trust it.

Even if you use something like VT-D, you've then got to program the IOMMU
and that has to be done in kernel for the same obvious reasons. Look at
VFIO.. maybe that helps.

Alan