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: <5051e5cb-89ea-b857-1288-1ac6bfe67872@c-s.fr>
Date:   Wed, 16 Jan 2019 14:34:53 +0100
From:   Christophe Leroy <christophe.leroy@....fr>
To:     Jonathan Neuschäfer <j.neuschaefer@....net>
Cc:     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



Le 16/01/2019 à 14:16, Jonathan Neuschäfer a écrit :
> 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.
> 

Yes right.


Would the following work instead ?

memblock_set_current_limit(0x20000000);


Christophe