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

Date:   Thu, 29 Apr 2021 20:04:17 +0200
From:   Thomas Bogendoerfer <tsbogend@...ha.franken.de>
To:     Huang Pei <huangpei@...ngson.cn>
Cc:     Zhou Yanjie <zhouyanjie@...yeetech.com>,
        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".

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 ?

Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.                                                [ RFC1925, 2.3 ]