linux-kernel - Re: [PATCH] Revert "MIPS: make userspace mapping young by default".

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] [day] [month] [year] [list]

Message-ID: <852b2950-fa4e-40cb-c18a-be8c3f8aa6e0@wanyeetech.com>
Date:   Sat, 8 May 2021 16:48:03 +0800
From:   Zhou Yanjie <zhouyanjie@...yeetech.com>
To:     Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
        Huang Pei <huangpei@...ngson.cn>
Cc:     linux-mips@...r.kernel.org, linux-kernel@...r.kernel.org,
        akpm@...ux-foundation.org, paul.burton@...s.com,
        paul@...pouillou.net, siyanteng@...ngson.cn, ira.weiny@...el.com,
        yangtiezhu@...ngson.cn, jun.jiang@...enic.com,
        dongsheng.qiu@...enic.com, aric.pzqi@...enic.com,
        rick.tyliu@...enic.com, sernia.zhou@...mail.com,
        sihui.liu@...enic.com
Subject: Re: [PATCH] Revert "MIPS: make userspace mapping young by default".

Hi,

On 2021/4/30 上午2:04, Thomas Bogendoerfer wrote:
> On Mon, Apr 26, 2021 at 09:11:47PM +0800, Huang Pei wrote:
>> [   40.873779] Cause : 4080800c (ExcCode 03)
>> [   40.877775] BadVA : 77e23000
>> [   40.880645] PrId  : 00d00100 (Ingenic XBurst)
>> [   40.884989] Modules linked in:
>> [   40.888034] Process Xsession (pid: 1370, threadinfo=ca5ce8d6,
>> task=61c8f3ad, tls=77e28690)
>>
>> !!! This is my first time debug MIPS32 kernel, I think both threadinfo
>> and task should be at KSEG0, instead of KSEG2 or USEG
> don't print pointers with %p they will be garbled for security reasons.
>
> see Documentation/core-api/printk-formats.rst
>
> "A raw pointer value may be printed with %p which will hash the address
> before printing."
>
>> [   41.233877] Index: 27 pgmask=4kb va=77e22000 asid=5c
>> [   41.233877]  [pa=06a17000 c=3 d=0 v=0 g=0] [pa=2017a000 c=0 d=0 v=0
>> g=0]
>>
>> !!! TLB entry is loading a SWAP entry(C=0, pa=swap) at BADV, the pte_buddy point to a valid
>> PFN(C=3, pa seem ok), but it is impossible, since line 116 must flush the tlb and
>> replaced swap entry with new page
>>
>> Am I missing something?
> not sure, if I'm on the right track, but with the _PAGE_VALID bit set in
> the new pte local_r4k_flush_cache_page() will do
>
>          if ((mm == current->active_mm) && (pte_val(*ptep) & _PAGE_VALID))
>                  vaddr = NULL;
>
>
> and then
>
> 	vaddr ? r4k_blast_dcache_page(addr) :
>                  r4k_blast_dcache_user_page(addr);
>
> flush the address directly instead with r4k_blast_dcache_user_page().
> But the TLB will be updated after the cache flush (which is correct IMHO).
> So setting the VALID bit too early destroys the logic of flushing
> cache aliases. Do you agree ?


I think it is indeed the problem here.

After I tried to drop the _PAGE_VALID mark in the PVA (change it to 
"#define PVA(p) PM(_PAGE_ACCESSED | (p))"), the kernel no longer panic.


Thanks and best regards!


>
> Thomas.
>