linux-kernel - Re: [PATCH v1 03/13] powerpc/mm/32s: rework mmu_mapin

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ee4322c4-60e1-94c5-1e55-5d4c3e4de03b@c-s.fr>
Date:   Tue, 18 Dec 2018 15:55:26 +0100
From:   Christophe Leroy <christophe.leroy@....fr>
To:     Jonathan Neuschäfer <j.neuschaefer@....net>
Cc:     linuxppc-dev@...ts.ozlabs.org, Paul Mackerras <paulus@...ba.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1 03/13] powerpc/mm/32s: rework mmu_mapin_ram()



Le 18/12/2018 à 15:15, Christophe Leroy a écrit :
> 
> 
> Le 18/12/2018 à 15:07, Jonathan Neuschäfer a écrit :
>> On Tue, Dec 18, 2018 at 09:18:42AM +0000, Christophe Leroy wrote:
>>> The only difference I see then are the flags. Everything else is seems
>>> identical.
>>>
>>> I know you tried already, but would you mind trying once more with the
>>> following change ?
>>>
>> [...]
>>> -        setbat(idx, PAGE_OFFSET + base, base, size, PAGE_KERNEL_TEXT);
>>> +        setbat(idx, PAGE_OFFSET + base, base, size, PAGE_KERNEL_X);
>>
>> Good call, with this workaround on top of patches 1-3, it boots again:
>>
>>     # mount -t debugfs d /sys/kernel/debug
>>     # cat /sys/kernel/debug/powerpc/block_address_translation
>>     ---[ Instruction Block Address Translation ]---
>>     0: 0xc0000000-0xc0ffffff 0x00000000 Kernel EXEC
>>     1:         -
>>     2: 0xc1000000-0xc17fffff 0x01000000 Kernel EXEC
>>     3:         -
>>     4: 0xd0000000-0xd1ffffff 0x10000000 Kernel EXEC
>>     5:         -
>>     6:         -
>>     7:         -
>>
>>     ---[ Data Block Address Translation ]---
>>     0: 0xc0000000-0xc0ffffff 0x00000000 Kernel RW
>>     1: 0xfffe0000-0xffffffff 0x0d000000 Kernel RW no cache guarded
>>     2: 0xc1000000-0xc17fffff 0x01000000 Kernel RW
>>     3:         -
>>     4: 0xd0000000-0xd1ffffff 0x10000000 Kernel RW
>>     5:         -
>>     6:         -
>>     7:         -
>>
>>> I think we may have some code trying to modify the kernel text 
>>> without using
>>> code patching functions.
>>
>> Is there any faster way than to sprinkle some printks in setup_kernel
>> and try to find the guilty piece of code this way?
> 
> Can you start with the serie 
> https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=75072 ?

Ok, the thing I was thinking about was the MMU_init_hw() but it is 
called before mapin_ram() so it should not be a problem. Not sure that 
serie improves anything at all here.

So there must be something else, pretty early (before the system is able 
to properly handle and display an Oops for write to RO area.)

Does anybody have an idea of what it can be ?

Christophe

> 
> Christophe
> 
>>
>>
>> Jonathan
>>