linux-kernel - RFC: staging: gasket: re-implement using UIO

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 for Android: free password hash cracker in your pocket

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

Date:   Tue, 6 Nov 2018 16:20:49 -0800
From:   Todd Poynor <toddpoynor@...gle.com>
To:     "Ahmed S. Darwish" <darwish.07@...il.com>
Cc:     Greg KH <gregkh@...uxfoundation.org>,
        Rob Springer <rspringer@...gle.com>,
        LKML <linux-kernel@...r.kernel.org>, devel@...uxdriverproject.org
Subject: RFC: staging: gasket: re-implement using UIO

On Mon, Sep 10, 2018 at 8:28 AM Ahmed S. Darwish <darwish.07@...il.com> wrote:
>
> The gasket in-kernel framework, recently introduced under staging,
> re-implements what is already long-time provided by the UIO
> subsystem, with extra PCI BAR remapping and MSI conveniences.
>
> Before moving it out of staging, make sure we add the new bits to
> the UIO framework instead, then transform its signle client, the
> Apex driver, to a proper UIO driver (uio_driver.h).
>
> Link: https://lkml.kernel.org/r/20180828103817.GB1397@do-kernel

So I'm looking at this for reals now.  The BAR mapping stuff is
straightforward with the existing framework.  Everything else could be
done outside of UIO via the existing device interface, but figured I'd
collect any opinions about adding the new bits to UIO.

The Apex device has 13 MSIX interrupts.  UIO does one IRQ per device.
The PRUSS driver registers 8 instances of the UIO device with
identical memory mappings but individual IRQs for its 8 interrupts.
Currently gasket has userspace pass down an eventfd (via ioctl) for
each interrupt it wants to watch.  Is there interest in modifying UIO
to handle multiple IRQs in some perhaps similar fashion?

Speaking of ioctls, are those allowed here, or is sysfs or something
else always required?  The aforementioned multiple IRQ stuff probably
maps nicely to sysfs (there's a small number of them easily
represented as attributes), while DMA buffer mappings seem more
problematic, but maybe somebody's thought of a good way to represent
these already.

And then we need to map buffers to our device.  We could probably
implement this via an IOMMU driver API for our custom MMU and hook
that up to generic IOMMU support for UIO, which sounds like something
a lot of drivers could use.

There's a few other tidbits the driver does, including allocating
coherent memory for userspace to share with the device, but that's
probably enough for now.

If anybody wants to squash any of the above as a non-starter for UIO
or point things in a different direction, it's appreciated.

Thanks,

Todd