linux-kernel - Re: [GIT *] Allow request_firmware() to be satisfied from in-kernel, use it in more drivers.

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:	Tue, 15 Jul 2008 22:21:10 +0200
From:	Marcel Holtmann <marcel@...tmann.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	David Woodhouse <dwmw2@...radead.org>,
	Frans Pop <elendil@...net.nl>, jeff@...zik.org,
	arjan@...radead.org, akpm@...ux-foundation.org,
	alan@...rguk.ukuu.org.uk, linux-kernel@...r.kernel.org
Subject: Re: [GIT *] Allow request_firmware() to be satisfied from
	in-kernel, use it in more drivers.

Hi Linus,

> > you don't have to. We extend udev once and then it will always work.
> 
> Umm. The thing is, people running new kernels with old user land is not 
> just supposed to work, it's _really_ supposed to work.
> 
> It's what I do. Something that breaks that has to have damn good reasons 
> to break it.

so request_firmware() is well established and works. It is used by a
bunch of drivers at the moment.

If we do wanna make more heavy use of it (which seems everybody is in
agreement) then we need to make some userspace changes like adding the
kernel version to keep it sane. This can be done step by step to make
sure we keep the current status quo.

And as David mentioned multiple times, he left drivers/{net,scsi} out of
it for now.

> So I do not disagree with Jeff on that point _at_all_. I'm in violent 
> agreement with Jeff on the fact that we should not require system updates 
> for the kernel to do the right thing.
> 
> The thing I disagree with Jeff on is that he then seems to turn that into 
> something very negative ("let's not separate the firmware at all").
> 
> And I'd much rather just fix it. And that means that if people can point 
> to udevd's that get confused - or lack of udevd's entirely - both of which 
> sound very likely to me, then we should have a graceful fallback position.
> 
> And just supporting the notion of loading the firmware directly sounds 
> like an obvious such case. It may not be the _only_ solution, for example, 
> which is why I'd actually like to see people point to the _actual_ 
> reported problems.

I really don't see that problem here since request_firmware() has been
around for so long now and so many drivers are using it nowadays that I
don't see your point here on how it will break.

However if you wanna make the kernel do the loading from the filesystem
directly, I am actually fine with it. We were opposed to that idea,
because it was always kinda hackish to have the kernel load files and it
felt wrong to do it this way. Policy decisions on directory layouts
belong into the userspace and not the kernel. At least that is my take
on this.

Regards

Marcel

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