linux-kernel - Re: [PATCH 001/001] CHAR DRIVERS: a simple device to give daemons a /sys-like interface

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] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 09 Aug 2013 16:35:16 -0700
From:	Bob Smith <bsmith@...uxtoys.org>
To:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
CC:	Arnd Bergmann <arnd@...db.de>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 001/001] CHAR DRIVERS: a simple device to give daemons
 a /sys-like interface

Greg Kroah-Hartman wrote:
> Good protocols exist, look at protobufs from Google if you want to
> define your own.  Never create your own protocol these days, it doesn't
> make sense, be it a text one or something else.

OK.  I was using the term in the broader sense in which _meaning_ is
assigned to the data in the protocol, not just the data marshaling.

>
>> - a C _binding_ to present a C API and hide the protocol for C programmers,
>> - a C++ binding and API for C++ programmers
>> - a Java binding
>> - a PHP binding
>> - a Perl binding
>> - a Python binding
>> - a node.js binding
>> - a Scratch binding for Raspberry Pi users
>> - and some kind of shell binding for Bash programmers
> All of those languages already support Linux syscalls, no need to create
> anything else.
Yes, we can publish the protocol and let the application writer
deal with it.  Bindings are nice only if you want to give a simple
API to the developer or want to hide the details of the protocol.

>
>>  From a kernel developer's point of view the term "userspace driver"
>> may seem like an oxymoron.  By definition, all devices on the system
>> have to be controlled by the kernel.  All else is just userspace.
>
> Not true at all, I know all about userspace drivers, look at the UIO
> code in the Linux kernel.  It was created explicitly for this exact
> thing, and to prevent the myrads of broken implementations from being
> created again and again and again.  Just use it if you wish to talk to
> your hardware directly, lots of people do so.
Well, not this exact thing.  UIO is great if your hardware hangs
on a bus directly connected to the CPU.  It does nothing to help
the case of hardware connected over some communications link.

>
>> As an _opinion_ only, I think maybe userspace device drivers do exist.
>> It refers to  hardware that the kernel is not, and should not, be aware
>> of.  This hardware is not seen because it is at the end of some kind of
>> communications channel like USB-serial or Ethernet. A developer might
>> like to view that hardware as part of the overall system even if Linux
>> and the CPU do not have direct access to it.  A userspace driver looks
>> something like this
>>
>> 	=(ProxyDevNode)====(daemon)===(CommChannel)===(hardware)
>
> Not really, you are just using an IPC to talk to a "real" device driver.

Yes, each of the "=" above has data passing through a real driver.

>
> FPGAs are interesting things, people are creating "real" drivers for
> them (see the linux-kernel archives for a few examples.)  Other people
> just use the UIO layer instead, which works quite well for them.  I
> suggest you do the same thing.

UIO can not see hardware at the end of a USB-serial link.

>
> Again, you are creating a new form of userspace/userspace IPC, without a
> good reason for why one of the existing IPC implementations will not
> work for you (no, being able to use "echo" is not a good reason, you can
> do that with local sockets just fine).
>
> I suggest you take a look at the book, The Linux Programming Interface,
> by Michael Kerrisk, specifically chapter 43, which goes into great
> detail about all of the existing IPC mechanisms that Linux already
> provides.  I'm sure one of them should be able to fit your needs.

Greg Kroah-Hartman wrote:
> Otherwise, to accept this code, I need to see a way that normal users
> can use it (i.e. no root or mknod), and that it can handle namespaces
> and the security interface that the kernel has to support.  To do so
> otherwise would be unfair to users who expect such a thing.

OK, this makes sense.

thanks
Bob Smith




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/