UIO Kernel Driver with Buildroot and QEMU

[Kenneth Adam Miller]

On Tue, Oct 20, 2015 at 8:17 PM, Greg KH <greg at kroah.com> wrote:

> On Tue, Oct 20, 2015 at 07:40:37PM -0400, Kenneth Adam Miller wrote:
> >
> > On Tue, Oct 20, 2015 at 6:54 PM, Greg KH <greg at kroah.com> wrote:
> >
> >     On Tue, Oct 20, 2015 at 11:58:21AM -0400, Kenneth Adam Miller wrote:
> >     > So I'm building a uio kernel driver with buildroot, and I've
> gotten the
> >     driver
> >     > to compile, installed it and can insmod it in the final buildroot
> target
> >     after
> >     > booting the image with QEMU.
> >     >
> >     > I'm on linux kernel version 3.14, and I followed the guide here:
> >     >
> >     >
> https://www.kernel.org/doc/htmldocs/uio-howto/userspace_driver.html
> >     >
> >     > And it describes the location on where the device file that should
> be
> >     opened by
> >     > userland code as either one of two locations:
> >     >
> >     > /dev/uioX, with X being a number
> >     >
> >     > or /sys/class/uio/uioX
> >     >
> >     > But the each of following returns nothing:
> >     >
> >     > ls /dev/uio*
> >     > ls /sys/class/uio/
> >     >
> >     > After I compile the uio example that is provided in the linux
> source at
> >     source/
> >     > drivers/uio/uio.c and uio_dmem_genirq.c, and insmod them, I do
> modprobe
> >     uio and
> >     > modprobe uio_dmem_genirq and each of those return nothing.
> However, I do
> >     see
> >     > that /sys/modules/uio and /sys/modules/uio_dmem_genirq
> >
> >     uio.ko is the uio "core", you need a uio driver in order to actually
> use
> >     it.
> >
> >     uio_dmem_genirq is a uio driver, have you added the needed device
> tree
> >     entries to have it actually create a device for you?  Without them,
> this
> >     driver can not find any hardware to bind to, and as such, no device
> node
> >     will ever be created.
> >
> >
> > I didn't know about that. How do I do that? I'm using buildroot; I guess
> > there's something missing in menuconfig or linux-menuconfig.
>
> Um, no, device tree doesn't have anything to do with buildroot, other
> than the fact that you need such a thing for your platform to work
> properly.
>

Well, often there are options and relation configurations that are
implicitly required by the target development objective that have to be
enabled by buildroot. For instance, right now I'm using devtempfs, and I
know that because one of the things I considered was that it was possible
that it was a silent failure on the part of the module insertion that it
wasn't creating the current /dev entry because it was static. But I
followed up in buildroot to make sure that I had it.


>
> >     I would suggest reading the UIO documentation, it should explain all
> of
> >     this for you already.  If not, specific questions are always gladly
> >     answered.
> >
> >
> > The one that I linked? I read that repeatedly. What other documentation
> is
> > there to read? I also read from Essential Linux Device Drivers, and none
> of
> > them explained that. There has to be something I'm missing.
>
> Step back, what exactly are you trying to do here that you think UIO is
> the answer?  Where is the uio driver that you want to run for your
> hardware platform?  UIO is a _very_ hardware-specific solution to a
> _very_ specific problem that people have, are you sure it's what you
> need?
>
>
Right now, we are building a security solution that requires that
communication be fully isolated by subject. We don't have special devices,
we actually have very special, extra security software that we're trying to
support. One of those is a permissions capability that can be set beneath
the guest that determines what memory can be observed or written to. If a
violation occurs, the guest is killed. We like this model because only the
data makes it through. The problem with doing it the old way was 1) it was
too slow. 2) it was very hard to write in a kernel module context, and
therefore it was overkill 3) all we really wanted was to facilitate the
ability to access special limited access memory.

So effectively, we are moving code that is currently in a driver, out of a
driver. In fact, all we want to do is map memory into user space, and then
access that memory as though it were an array in the user land code.


> thanks,
>
> greg k-h
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20151020/6f64660e/attachment.html