linux-kernel - Re: [PATCH v2] powerpc 8xx: Fixing issue with CONFIG_PIN

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:	Fri, 20 Sep 2013 16:22:21 -0500
From:	Scott Wood <scottwood@...escale.com>
To:	leroy christophe <christophe.leroy@....fr>
CC:	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Paul Mackerras <paulus@...ba.org>,
	<linux-kernel@...r.kernel.org>, <linuxppc-dev@...ts.ozlabs.org>,
	Joakim Tjernlund <joakim.tjernlund@...nsmode.se>
Subject: Re: [PATCH v2] powerpc 8xx: Fixing issue with CONFIG_PIN_TLB

On Tue, 2013-09-17 at 18:40 +0200, leroy christophe wrote:
> Le 16/09/2013 23:02, Scott Wood a écrit :
> > On Fri, 2013-09-13 at 07:04 +0200, leroy christophe wrote:
> >> Le 12/09/2013 20:44, Scott Wood a écrit :
> >>> On Thu, 2013-09-12 at 20:25 +0200, Christophe Leroy wrote:
> >>>> This is a reorganisation of the setup of the TLB at kernel startup, in order
> >>>> to handle the CONFIG_PIN_TLB case in accordance with chapter 8.10.3 of MPC866
> >>>> and MPC885 reference manuals.
> >>>>
> >>>> Signed-off-by: Christophe Leroy <christophe.leroy@....fr>
> >>>>
> >>>> diff -ur linux-3.11.org/arch/powerpc/kernel/head_8xx.S linux-3.11/arch/powerpc/kernel/head_8xx.S
> >>>> --- linux-3.11.org/arch/powerpc/kernel/head_8xx.S	2013-09-02 22:46:10.000000000 +0200
> >>>> +++ linux-3.11/arch/powerpc/kernel/head_8xx.S	2013-09-09 11:28:54.000000000 +0200
> >>>> @@ -785,27 +785,24 @@
> >>>>     * these mappings is mapped by page tables.
> >>>>     */
> >>>>    initial_mmu:
> >>>> -	tlbia			/* Invalidate all TLB entries */
> >>>> -/* Always pin the first 8 MB ITLB to prevent ITLB
> >>>> -   misses while mucking around with SRR0/SRR1 in asm
> >>>> -*/
> >>>> -	lis	r8, MI_RSV4I@h
> >>>> -	ori	r8, r8, 0x1c00
> >>>> -
> >>>> +	lis	r8, MI_RESETVAL@h
> >>>>    	mtspr	SPRN_MI_CTR, r8	/* Set instruction MMU control */
> >>>>    
> >>>> -#ifdef CONFIG_PIN_TLB
> >>>> -	lis	r10, (MD_RSV4I | MD_RESETVAL)@h
> >>>> -	ori	r10, r10, 0x1c00
> >>>> -	mr	r8, r10
> >>>> -#else
> >>>>    	lis	r10, MD_RESETVAL@h
> >>>> -#endif
> >>>>    #ifndef CONFIG_8xx_COPYBACK
> >>>>    	oris	r10, r10, MD_WTDEF@h
> >>>>    #endif
> >>>>    	mtspr	SPRN_MD_CTR, r10	/* Set data TLB control */
> >>>>    
> >>>> +	tlbia			/* Invalidate all TLB entries */
> >>> Is this change to make sure we invalidate everything even if the
> >>> bootloader set RSV4I?
> >> Most probably. It is step 2 of the process defined in MPC866 and MPC885
> >> Reference Manuals:
> >>
> >> §8.10.3 Loading Locked TLB Entries:
> >> The process of loading a single reserved entry in the TLB is as follows:
> > To minimize code churn we should just fix actual problems, rather than
> > shuffle things around to conform to a suggested sequence.  After all,
> > we're not just trying to load a single entry.
> Ok, I'll try again.
> >
> >>>> +	ori	r8, r8, 0x1c00
> >>>> +	mtspr	SPRN_MI_CTR, r8	/* Set instruction MMU control */
> >>>> +#ifdef CONFIG_PIN_TLB
> >>>> +	ori	r10, r10, 0x1c00
> >>>> +	mtspr	SPRN_MD_CTR, r10	/* Set data TLB control */
> >>>> +#endif
> >>> Still 0x1c00?
> >> Yes, I kept the same entries in order to limit modifications:
> >> * 28 = First 8Mbytes page
> >> * 29 = IMMR
> >> * 30 = Second 8Mbytes page
> >> * 31 = Third 8Mbytes page
> > If you actually want to program them in increasing order then it looks
> > like you're still missing a write to CTR between the last two 8M entries
> > -- thus you'll overwrite the IMMR with the last 8M entry.  That was the
> > same problem that v1 fixed -- did that change get lost accidentally?
> Oops, no, in fact I diffed from the version which was including it 
> already. My mistake.
> >
> > The hardware wants to decrement; why fight it?
> I see your point.
> However it is not clear in the documentation if the decrement is done 
> really after the update, or at xTLB interrupt. So I propose to still set 
> the CTR ourself as described in the reference Manual and not assume that 
> the HW decrements it.

It says "every update" -- do you have any reason to believe that's
wrong?  It could be tested...

-Scott



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