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
| ||
|
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/
Powered by blists - more mailing lists