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]
Message-Id: <200708091723.57041.hjk@linutronix.de>
Date:	Thu, 9 Aug 2007 17:23:56 +0200
From:	Hans-Jürgen Koch <hjk@...utronix.de>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Valdis.Kletnieks@...edu, 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 16:12 schrieb Alan Cox:
> > 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.
> 
> This I believe incorrect. Please cite caselaw if you know better.

What about the statement at the top of COPYING in the top level kernel source 
directory?

I know, you've got examples in mind where a kernel module and a userspace
program are dependent on each other and none of them can be used without the 
other. Of course, we've got such a case for a UIO kernel module and userspace
driver. But if the degree of dependency between kernel and userspace can
constitute a different legal situation, then we have a _very_ large legal
grayzone.

> 
> > 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.
> 
> False
> 
> Because you have no idea if the interface is correct or the userspace is
> doing stuff like triggering DMA to arbitary addresses via the interface
> or mmap functions. If it does so then even if its root only you've blown
> your security model.

OK, I agree. But in comparison to using /dev/mem for these tasks, I still 
consider UIO an improvement. 

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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ