linux-kernel - Re: [2.6.25-rc5-mm1] BUG: spinlock bad magic early during boot

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: <20080324171924.GB3782@elf.ucw.cz>
Date:	Mon, 24 Mar 2008 18:19:24 +0100
From:	Pavel Machek <pavel@....cz>
To:	Eric Piel <eric.piel@...mplin-utc.net>
Cc:	Dave Hansen <haveblue@...ibm.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Tilman Schmidt <tilman@...p.cc>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, Thomas Renninger <trenn@...e.de>,
	Len Brown <len.brown@...el.com>,
	Christoph Hellwig <hch@...radead.org>,
	Markus Gaugusch <dsdt@...gusch.at>, linux-acpi@...r.kernel.org,
	Al Viro <viro@...IV.linux.org.uk>,
	Arjan van de Ven <arjanv@...hat.com>,
	Eric Biederman <ebiederm@...ssion.com>
Subject: Re: [2.6.25-rc5-mm1] BUG: spinlock bad magic early during boot

On Mon 2008-03-24 18:05:14, Eric Piel wrote:
> Pavel Machek wrote:
>> Hi!
>>> Can we use kexec for this?  Let's say you get as far in boot as the
>>> initrd and realize that you're running on one of these screwed up
>>> systems.  Can you stick the new DSDT somewhere known (and safe) in
>>> memory, and kexec yourself back to the beginning of the kernel boot?
>>>
>>> When you boot up the second time, you have the new, shiny DSDT there
>>> which is, of course, used instead of the bogus BIOS one.
>>>
>>> It costs you some bootup time, but we're talking about working around
>>> really busted hardware here.  
>>
>> Hmmm. I guess we should turn off acpi mode, kexec, turn on acpi mode
>> with new dsdt.
>>
>> Turning off acpi is not exactly easy, but specs describe how to do
>> it...
> Why do you think it's necessary to turn off acpi mode? What will not work 
> if we keep it on all the time?
>
> BTW, let me summarize my understanding of the kexec approach:
> * the userspace write the new DSDT (cat my-dsdt-image > 
> /sys/firmware/acpi/tables/DSDT)
> * the kernel don't use this DSDT directly but keeps it somewhere warm and 
> fuzzy in the RAM
> * userspace does a kexec
> * the new kernel boots and at some (early) point, dsdt_override() is 
> called. It detects that the special place in the RAM for a new DSDT is 
> used. It provides this pointer to ACPI as the new place to read the
> DSDT.

Yes, and now ACPI layer tries to enable already enabled ACPI... which
is no-no according to spec, but you may be able to  get away with it.

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
pomozte zachranit klanovicky les:  http://www.ujezdskystrom.info/
--
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/