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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20180406130146.5a9c7ff3@alans-desktop>
Date:   Fri, 6 Apr 2018 13:01:46 +0100
From:   Alan Cox <gnomes@...rguk.ukuu.org.uk>
To:     Simon Que <sque@...omium.org>
Cc:     linux-kernel@...r.kernel.org, frankhu@...omium.org,
        John Joseph <jnjoseph@...gle.com>,
        Rob Springer <rspringer@...gle.com>
Subject: Re: Looking for way to program external MMU from userspace (or
 viable alternative)

> 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