linux-kernel - Re: start_kernel(): bug: interrupts were enabled early

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: <1270104536.7101.114.camel@pasglop>
Date:	Thu, 01 Apr 2010 17:48:56 +1100
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	"H. Peter Anvin" <hpa@...or.com>,
	Christoph Lameter <cl@...ux-foundation.org>,
	Matthew Wilcox <matthew@....cx>,
	Yinghai Lu <yinghai@...nel.org>, Rabin Vincent <rabin@....in>,
	lkml <linux-kernel@...r.kernel.org>, penberg@...helsinki.fi,
	linux-arch@...r.kernel.org
Subject: Re: start_kernel(): bug: interrupts were enabled early

On Wed, 2010-03-31 at 23:33 -0400, Andrew Morton wrote:
> Just a few instructions, I guess.   But we can do it with zero.
> 
> And from a design POV, pretending that down_read()/down_write() can be
> called with interrupts disabled is daft - they cannot!  Why muck up
> the
> usual code paths with this startup-specific hack? 

Because we the problem of when interrupts are enabled for the first time
is a nasty one, and having entire layer of things not usable at the
right level of init because somewhere something might do an irq enable
due to calling generic code that down's a semaphore is a PITA.

Seriously, Andrew, I don't see a clean solution... Something -somewhere-
will have to be ugly.

Allocation is a pretty basic service that a lot of stuff expect
especially when booting.

We went through that discussion before when we moved the SLAB init
earlier during boot, because it makes no sense to have tons of code to
have to figure out what allocator to call depending on what phase of the
moon it's called from (especially when said code can also be called
later during boot, say for hotplug reasons).

So we moved sl*b init earlier, thus we ought to be able to also
kmem_cache_alloc() earlier. We -fixed- that problem already afaik.

Cheers,
Ben.

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