linux-kernel - Re: Class device namespaces

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:	Wed, 29 Apr 2009 21:10:56 +0200
From:	Kay Sievers <kay.sievers@...y.org>
To:	Michael Brown <mebrown@...haels-house.net>
Cc:	Doug Warzecha <Douglas_Warzecha@...l.com>,
	Jean Delvare <khali@...ux-fr.org>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	linux-kernel@...r.kernel.org,
	Mauro Carvalho Chehab <mchehab@...radead.org>,
	Matt Domsch <Matt_Domsch@...l.com>
Subject: Re: Class device namespaces

On Wed, Apr 29, 2009 at 19:00, Michael Brown <mebrown@...haels-house.net> wrote:
> On Wed, Apr 29, 2009 at 5:30 AM, Kay Sievers <kay.sievers@...y.org> wrote:

>> Yeah, maybe you can not use the in-kernel firmware-request filled
>> memory. But you can copy it just fine, once it is in the kernel. There
>> is no reason to fiddle around with chunks here in userspace.
>
> Pretty much describes exactly what dell_rbu does, except that the
> in-kernel packetizing code was rejected on our first submission, so we
> moved it into userspace.

That's the wrong reason to reject anything like that. I mean, you
should not use that interface at all for stuff like that, but
rejecting it for that reason seem wrong.

>> How do you make sure udev does not handle the request at the same
>> time? This interface is not public at all, on a general system. As
>> long as udev is active you can not use it at all. Udev will run at the
>> same time and write to the same files, and even cancel the request if
>> the requested file is not found. How does your software cope with
>> that?
>
> That is a very interesting question, as I've never seen udev do
> anything to interfere with our process. We dont do anything special to
> disable udev. Like I said above, we scribble some values to one file,
> wait for the request_firmware() files to appear and write stuff to
> them when they do. Udev hasnt ever tried to handle this that I have
> seen, especially since we dont have any appropriate files sitting
> around that udev would ever have access to in order to feed
> request_firmware().

Udev runs exactly at the time you create the device, and is not
unlikely faster than your polling, at least not predictable slower.
And it will cancel all requests which can not be fulfilled by udev
itself.

I strongly recommend switching to a different solution, you can not
use the firmware_class interface on any udev system, the interface is
already taken, and it's a single-user interface the way it is
implemented today. That it seems to work for you, is pure luck, I
guess. :)

Thanks,
Kay
--
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/