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]

Date:	Mon, 29 Aug 2011 23:14:39 +0200
From:	Borislav Petkov <bp@...en8.de>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Arnaud Lacombe <lacombar@...il.com>,
	David Airlie <airlied@...hat.com>,
	Michel Dänzer <michel@...nzer.net>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	dri-devel@...ts.freedesktop.org, Pavel Ivanov <paivanof@...il.com>,
	Alex Deucher <alexdeucher@...il.com>,
	Dave Airlie <airlied@...il.com>, linux-kbuild@...r.kernel.org
Subject: Re: Kernel almost hangs when CONFIG_DRM_RADEON=y

On Mon, Aug 29, 2011 at 08:16:53PM +0200, Peter Zijlstra wrote:
> On Mon, 2011-08-29 at 20:09 +0200, Peter Zijlstra wrote:
> > > That would suck, suppose this radeon thing is the only console you've
> > > got (ppc64/sparc64 don't have text mode iirc) and userspace doesn't come
> > > up?
> > 
> > Same is true for NICs and netconsole of course. Not being able to stick
> > blobs into the kernel image would so suck. 
> 
> NICs and nfsroot, I suppose can you use an initrd over tftp as well, but
> really, what's the point of an in-kernel nfsroot if you need initrd
> crap.

Damn,

just when I thought that the lofty goal of Linux distancing itself from
firmware crap is within reach, you came up with all those real-life,
nagging examples.

So here's the whole deal IMHO:

* driver =m and request_firmware() works fine - you only need the blobs
in the right place.

* driver =y and request_firmware() should be fixed in all cases where
driver can wait.

Your use cases could probably be addressed by supplying firmware blobs
from the bootloader. We had this talk already concerning CPU microcode
updates and how the current method is to load CPU ucode when the module
gets loaded, which might be too late for some obscure (and not so
obscure) cases.

So, hypothetically speaking, hpa suggested then that we could pass
firmware blobs over the linked list setup_data thing in the real-mode
kernel header and parse_setup_data() can look at them and map them
somewhere later for the driver to find. This should be doable because
you're only gonna need a handful of blobs for CPU ucode, network and GPU
if the last is compiled in.

I wanted to take a serious look at that for the ucode loading, maybe I
should try to shuffle some time for it...

-- 
Regards/Gruss,
    Boris.
--
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/