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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Tue, 18 Dec 2018 16:04:42 +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:55, Christophe Leroy a écrit :
> 
> 
> 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 ?


Stupid of me. In fact at the time being, BATS cover both RO and RW data 
areas, so it can definitly not be mapped with PAGE_KERNEL_ROX.

In fact, as I have CONFIG_BDI_SWITCH in my setup, PAGE_KERNEL_TEXT is 
PAGE_KERNEL_X on my side. That's the reason why I missed it.

With this change being done to patch 3, does the overall serie works for 
you ?

Thanks
Christophe



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