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: <20110830071755.GB15134@liondog.tnic>
Date:	Tue, 30 Aug 2011 09:17:56 +0200
From:	Borislav Petkov <bp@...en8.de>
To:	Henrique de Moraes Holschuh <hmh@....eng.br>
Cc:	Peter Zijlstra <peterz@...radead.org>,
	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 11:08:28PM -0300, Henrique de Moraes Holschuh wrote:
> On Mon, 29 Aug 2011, Borislav Petkov wrote:
> > 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...
> 
> It would be very useful, yes.
> 
> Alternatively, you could extend the initrd format to have a firmware
> directory appended after the filesystem image.  ACPI is going to abuse
> the initrd in just that way to override ACPI tables very soon (patches
> have been already submitted to linux-acpi),

.. lemme guess: they didn't put the correct tables in the BIOS in the
first place and now it is too late for a BIOS fix and want to shuffle in
all those "fixes" through initrd ontop of ACPI. Oh boy, do I love all
the ACPI crap stories :).

> so if a more structured and extensible way to piggy-back early-init
> data in the initrd is needed, it would be good to bring that to the
> table NOW.

Yeah, that's not more than an idea right now, I haven't even started
playing with it. If it turns out to be more superior, it could be reused
for other things too but right now it's too early to tell.

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