linux-kernel - Re: Kernel almost hangs when CONFIG_DRM

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: <CAGZ=bqKHvauaW8jdPR98d-X5dry_pADYHWH-OsJE_CXT9hdwVw@mail.gmail.com>
Date:	Mon, 29 Aug 2011 12:28:31 -0400
From:	Kyle Moffett <kyle@...fetthome.net>
To:	Alex Deucher <alexdeucher@...il.com>
Cc:	Borislav Petkov <bp@...en8.de>,
	Peter Zijlstra <peterz@...radead.org>,
	Pavel Ivanov <paivanof@...il.com>,
	Michel Dänzer <michel@...nzer.net>,
	dri-devel@...ts.freedesktop.org,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: Kernel almost hangs when CONFIG_DRM_RADEON=y

On Mon, Aug 29, 2011 at 09:48, Alex Deucher <alexdeucher@...il.com> wrote:
> 2011/8/29 Borislav Petkov <bp@...en8.de>:
>> On Mon, Aug 29, 2011 at 03:20:21PM +0200, Peter Zijlstra wrote:
>>> On Sun, 2011-08-28 at 07:36 +0200, Borislav Petkov wrote:
>>> > > > With CONFIG_DRM_RADEON=y, the microcode is needed before it can be
>>> > > > loaded from userspace, so it needs to be built into the kernel as well.
>>> > >
>>> > > How should I do that? I've tried to set all "m"s to "y" in .config and
>>> > > still saw this issue. Should I set some special parameter?
>>> >
>>> > You need to add "radeon/CEDAR_pfp.bin" to CONFIG_EXTRA_FIRMWARE when you
>>> > configure your kernel and enable CONFIG_FIRMWARE_IN_KERNEL.
>>> >
>>> > The radeon/CEDAR_pfp.bin file (+ leading directory, mind you) should
>>> > most probably be located in /lib/firmware or to whatever you have set
>>> > CONFIG_EXTRA_FIRMWARE_DIR so that Kbuild can find it (if not, you'll get
>>> > a warning at the end of the kernel build). This way, it works for both
>>> > radeon being =m and =y.
>>>
>>> Should we make Kconfig pop up a dialog and ask for the whereabouts of
>>> these firmware thingies when you mark the driver =y?
>>>
>>> This all sounds like magic to me, having to know you need to add to
>>> EXTRA_FIRMWARE, having to know what file it needs etc.. For all intents
>>> and purposes =y just doesn't work and that's broken.
>>
>> Yep, you make a lot of sense. I had to fumble the build/reboot cycle a
>> couple of times and do some code staring even to figure this out. In
>> the end, I copied the whole radeon/ folder from David's firmware git
>> repo into /lib/firmware and made radeon.ko =m again so that I don't have
>> to add *.bin entries to CONFIG_EXTRA_FIRMWARE each time I'm building a
>> kernel on a different machine.
>>
>> Besides, there was this other issue on lkml today where
>> CONFIG_EXTRA_FIRMWARE can cause nconf to segfault when you overflow
>> its length of 256 by trying to include a bunch of firmware *bin files:
>> http://lkml.org/lkml/2011/8/29/86
>
> If you are going to build the ucode into your kernel you'll need to
> pick the ones you want to include or increase the limit regardless of
> whether it's radeon ucode or ucode for some other chip.  For a
> particular card you only need the ones for that card (e.g.,
> CEDAR_*.bin or REDWOOD_*.bin, etc.)

No, Linus pushed back really hard last time this issue came up with
something; a network driver if I recall correctly.

The issue is that this happens *EVEN FOR MODULAR DRIVERS* during
suspend/resume.  The firmware simply may not be available yet.

If the driver fundamentally cannot work without the firmware then it should
bind to the device and wait until the first userspace action before requesting
firmware.

Furthermore, the trend is generally to push the firmware OUT of the kernel
binary to avoid any chance of license issues.  Even if the code is built-in
it should not need built-in firmware.

The quickest fix is probably something like this:

config DRM_RADEON_FIRMWARE
        tristate
        default m if STANDALONE
        default y

config DRM_RADEON
        depends DRM_RADEON_FIRMWARE

That should prevent somebody from building the radeon driver into the
kernel unless they manually indicate that they have the extra firmware.

Long-term, the driver should support modular firmware even when it's
built-in to the kernel.

Cheers,
Kyle Moffett
--
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/