linux-kernel - Re: 2.6.18-rc6-mm1: GPF loop on early 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]

Date:	Sun, 10 Sep 2006 15:26:14 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Andi Kleen <ak@...e.de>
Cc:	Laurent Riffard <laurent.riffard@...e.fr>,
	Arjan van de Ven <arjan@...radead.org>,
	Andrew Morton <akpm@...l.org>,
	Kernel development list <linux-kernel@...r.kernel.org>,
	Jeremy Fitzhardinge <jeremy@...source.com>
Subject: Re: 2.6.18-rc6-mm1: GPF loop on early boot

* Andi Kleen <ak@...e.de> wrote:

> > Basically, non-atomic setup of basic architecture state _is_ going to be
> > a nightmare, lockdep or not, especially if it uses common infrastructure
> > like 'current', spin_lock() or even something as simple as C functions.
> > (for example the stack-footprint tracer was once hit by this weakness of
> > the x86_64 code)
> 
> I disagree with that.  The nightmare is putting stuff that needs so 
> much infrastructure into the most basic operations.

ugh, "having a working current" is "so much infrastructure" ?? Lockdep 
uses a very low amount of infrastructure, considering its complexity: it 
has its own allocator, uses raw spinlocks, raw irq flags ops, it 
basically implements its own infrastructure for everything. Being able 
to access a per-task data area (current) is a quite fundamental thing 
for kernel code.

the i686 PDA patches introduce tons of early_current() uses. While i 
like the new PDA code, its bootstrap (like x86_64's PDA bootstrap) is 
too fragile in my opinion, and it will regularly hit instrumenting 
patches.

Perhaps the early setup code (if we really want to do it all in C) 
should be moved into 32-bit early boot userspace code (like 
compressed/misc.c) and it will thus not depend on any kernel 
infrastructure.

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