linux-kernel - Re: [PATCH 2/3] UIO: Documentation

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]

Message-Id: <200708091502.45417.hjk@linutronix.de>
Date:	Thu, 9 Aug 2007 15:02:45 +0200
From:	Hans-Jürgen Koch <hjk@...utronix.de>
To:	Valdis.Kletnieks@...edu
Cc:	Jesper Juhl <jesper.juhl@...il.com>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/3] UIO: Documentation

Am Donnerstag 09 August 2007 00:12 schrieb Valdis.Kletnieks@...edu:

> 
> If you have UIO in the kernel talking to stuff in userspace, you're going to
> have to deal with closed-source stuff at the userspace end of the pipe.

That's no UIO invention. Userspace software that uses kernel interfaces like
syscall, device files, sysfs, and so on, is by definition _not_ a derived work
of the kernel and can be distributed under any license.

If you ask a manufacturer of an industrial IO card for a Linux driver today, 
you either get nothing at all, or you get an unmaintainable and buggy piece
of crap for an ancient kernel. The alternative is a binary kernel module that 
really violates the GPL.

With UIO, you have a kernel module that is so small, that even somebody who
hasn't got the hardware can easily review it and tell if the code is OK or not.
It is easy to maintain and doesn't reveal any secrets about the hardware.
The kernel remains clean, which further improves maintenance and debugging.
People frequently use /dev/mem to access hardware from userspace, that's
nothing new. UIO really improves this, making it safer and more user friendly.
And it prevents people from inventing dirty tricks to do some sort of 
interrupt handling in user space (which is simply not possible).

Furthermore, drivers for this kind of hardware are written by programmers in
industry, who often don't have kernel experience, reviews, time for tests,
and so on. I really prefer it if they do their stuff in userspace. And they
prefer it, too, because they can use all the nice tools and libraries they're
used to.

There might be a small possibility that a manufacturer now writes a closed
source UIO driver, and would have written an open source kernel driver if
UIO didn't exist. But, honestly, I doubt that we'll find many such cases.

Thanks,
Hans

-
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/