linux-kernel - Re: Make sure we populate the initroot filesystem late enough

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: <Pine.LNX.4.64.0702261315080.12485@woody.linux-foundation.org>
Date:	Mon, 26 Feb 2007 13:17:45 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	David Woodhouse <dwmw2@...radead.org>
cc:	Milton Miller <miltonm@....com>,
	LKML <linux-kernel@...r.kernel.org>, linuxppc-dev@...abs.org
Subject: Re: Make sure we populate the initroot filesystem late enough

On Mon, 26 Feb 2007, David Woodhouse wrote:
> 
> Now I'm starting to wonder if it's something the firmware sets up to DMA
> to a certain region of memory, which makes it non-deterministic. And the
> other things we're blaming are only making a difference because they
> change the layout of what we have in memory.

USB controller issues? We used to have these really hard-to-debug problems 
with the USB controller being active and having had the BIOS set up the 
command queues etc. Really subtle. It's why we now have PCI quirks for 
shutting up (most) USB controllers very early.

If there is some USB controller that we miss, or that sets up its command 
chain to some unexpected area (so that USB is active and corrupting memory 
even very early on), that could explain it.

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