UIO Kernel Driver with Buildroot and QEMU

[Kenneth Adam Miller]

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

> On Tue, Oct 20, 2015 at 08:28:20PM -0400, Kenneth Adam Miller wrote:
> > 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:
> >     > 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.
>
> Again, device tree is not a kernel build "option", it is provided by the
> firmware of your platform and handed to the kernel.  It describes your
> hardware to the kernel for systems that do not have discoverable
> hardware (like USB or PCI).
>
> >     >     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.
>
> How does that relate to UIO?
>
> The kernel already provides userspace isolation to memory, no need to
> add anything else, the hardware of the CPU does this for you
> automatically.
>
>
It provides some isolation. But there is no guarantee that any of the
machine code is perfect, be it our own or the kernel's. So we take a policy
where we just assume that it will have some kind of critical bug. In this
case, the whole program stops - OS included.

The OS does provide a version of each of the above, separation and memory
isolation. But we have our own. The unique requirement that the software
places on us is that we have specific hardware address regions that must be
mapped to specific processes. To do that, we want to have a kernel driver
map that back into user space 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.
>
> You don't need UIO for that, just use /dev/mem/ or other such
> functionality for that.  UIO is to allow userspace access to physical
> hardware that is memory-backed, and interrupts for that hardware.  If
> you just want access to real memory, no need to use UIO for that at all.
>
>
So dev/mem would allow the user space process to access a specific memory
region? Wow, I had no idea about that. If that's the case, you've helped us
tremendously because now we don't even have to write a driver at all.


> good luck!
>
> greg k-h
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20151020/92a493bb/attachment-0001.html