linux-kernel - Re: [PATCH v2 00/15] powerpc/32s: Use BATs/LTLBs for STRICT_KERNEL

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: <20190116131637.GF22334@latitude>
Date:   Wed, 16 Jan 2019 14:16:37 +0100
From:   Jonathan Neuschäfer <j.neuschaefer@....net>
To:     Christophe Leroy <christophe.leroy@....fr>
Cc:     Jonathan Neuschäfer <j.neuschaefer@....net>,
        Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        Paul Mackerras <paulus@...ba.org>,
        Michael Ellerman <mpe@...erman.id.au>,
        linux-kernel@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org
Subject: Re: [PATCH v2 00/15] powerpc/32s: Use BATs/LTLBs for
 STRICT_KERNEL_RWX

On Wed, Jan 16, 2019 at 07:55:29AM +0100, Christophe Leroy wrote:
> Le 16/01/2019 à 01:35, Jonathan Neuschäfer a écrit :
> > Thinning the kernel down a bit actually makes it boot again. Ooops...!
> > Maybe enabling CONFIG_STRICT_KERNEL_RWX has made it just large enough to
> > fail the hash table allocation, but there may have been other factors
> > involved (I'm not sure exactly).  Sorry for the confusion!
> 
> Ok, that must be the reason. Thanks for testing.
> 
> What about the following modification which maps a second 256Mb BAT, does it
> helps ?
> 
> 
> 
> diff --git a/arch/powerpc/kernel/head_32.S b/arch/powerpc/kernel/head_32.S
> index c2f564690778..ea574596de37 100644
> --- a/arch/powerpc/kernel/head_32.S
> +++ b/arch/powerpc/kernel/head_32.S
> @@ -1160,6 +1160,14 @@ initial_bats:
>  	mtspr	SPRN_DBAT0U,r11		/* bit in upper BAT register */
>  	mtspr	SPRN_IBAT0L,r8
>  	mtspr	SPRN_IBAT0U,r11
> +#ifdef CONFIG_WII
> +	addis	r11,r11,0x10000000@h
> +	addis	r8,r8,0x10000000@h
> +	mtspr	SPRN_DBAT2L,r8
> +	mtspr	SPRN_DBAT2U,r11
> +	mtspr	SPRN_IBAT2L,r8
> +	mtspr	SPRN_IBAT2U,r11
> +#endif
>  	isync
>  	blr
> 
> diff --git a/arch/powerpc/mm/ppc_mmu_32.c b/arch/powerpc/mm/ppc_mmu_32.c
> index 3f4193201ee7..a334fd5210a8 100644
> --- a/arch/powerpc/mm/ppc_mmu_32.c
> +++ b/arch/powerpc/mm/ppc_mmu_32.c
> @@ -259,6 +259,8 @@ void setup_initial_memory_limit(phys_addr_t
> first_memblock_base,
>  	/* 601 can only access 16MB at the moment */
>  	if (PVR_VER(mfspr(SPRN_PVR)) == 1)
>  		memblock_set_current_limit(min_t(u64, first_memblock_size, 0x01000000));
> +	else if (IS_ENABLED(CONFIG_WII))
> +		memblock_set_current_limit(min_t(u64, first_memblock_size, 0x20000000));
>  	else /* Anything else has 256M mapped */
>  		memblock_set_current_limit(min_t(u64, first_memblock_size, 0x10000000));
>  }

I haven't tested it, but this patch won't be enough, because we're only
looking at the first memblock, and the additional memory in the Wii
(MEM2) is the second memblock.


Jonathan

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)