linux-kernel - Re: [POWERPC][v2] Bolt in SLB entry for kernel stack on secondary cpus

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: <20080502055648.GA28378@yookeroo.seuss>
Date:	Fri, 2 May 2008 15:56:48 +1000
From:	David Gibson <david@...son.dropbear.id.au>
To:	Paul Mackerras <paulus@...ba.org>
Cc:	linuxppc-dev@...abs.org, linux-kernel@...r.kernel.org
Subject: Re: [POWERPC][v2] Bolt in SLB entry for kernel stack on secondary
	cpus

On Fri, May 02, 2008 at 02:29:12PM +1000, Paul Mackerras wrote:
> This fixes a regression reported by Kamalesh Bulabel where a POWER4
> machine would crash because of an SLB miss at a point where the SLB
> miss exception was unrecoverable.  This regression is tracked at:
> 
> http://bugzilla.kernel.org/show_bug.cgi?id=10082
> 
> SLB misses at such points shouldn't happen because the kernel stack is
> the only memory accessed other than things in the first segment of the
> linear mapping (which is mapped at all times by entry 0 of the SLB).
> The context switch code ensures that SLB entry 2 covers the kernel
> stack, if it is not already covered by entry 0.  None of entries 0
> to 2 are ever replaced by the SLB miss handler.
> 
> Where this went wrong is that the context switch code assumes it
> doesn't have to write to SLB entry 2 if the new kernel stack is in the
> same segment as the old kernel stack, since entry 2 should already be
> correct.  However, when we start up a secondary cpu, it calls
> slb_initialize, which doesn't set up entry 2.  This is correct for
> the boot cpu, where we will be using a stack in the kernel BSS at this
> point (i.e. init_thread_union), but not necessarily for secondary
> cpus, whose initial stack can be allocated anywhere.  This doesn't
> cause any immediate problem since the SLB miss handler will just
> create an SLB entry somewhere else to cover the initial stack.
> 
> In fact it's possible for the cpu to go quite a long time without SLB
> entry 2 being valid.  Eventually, though, the entry created by the SLB
> miss handler will get overwritten by some other entry, and if the next
> access to the stack is at an unrecoverable point, we get the crash.
> 
> This fixes the problem by making slb_initialize create a suitable
> entry for the kernel stack, if we are on a secondary cpu and the stack
> isn't covered by SLB entry 0.  This requires initializing the
> get_paca()->kstack field earlier, so I do that in smp_create_idle
> where the current field is initialized.  This also abstracts a bit of
> the computation that mk_esid_data in slb.c does so that it can be used
> in slb_initialize.
> 
> Signed-off-by: Paul Mackerras <paulus@...ba.org>
> ---
> Michael Ellerman pointed out that I should be comparing
> raw_smp_processor_id() with boot_cpuid rather than with 0.

Do you even need the processor ID test at all?  The boot processor
should always have its stack covered by SLB entry 0 when we come
through here, shouldn't it?

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson
--
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/