linux-kernel - Re: [PATCH 01/11] Initialize the mapping of KASan shadow memory

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: <20171118134841.3f6c9183@why.wild-wind.fr.eu.org>
Date:   Sat, 18 Nov 2017 13:48:41 +0000
From:   Marc Zyngier <marc.zyngier@....com>
To:     "Liuwenliang (Abbott Liu)" <liuwenliang@...wei.com>
Cc:     Christoffer Dall <cdall@...aro.org>,
        "linux@...linux.org.uk" <linux@...linux.org.uk>,
        "aryabinin@...tuozzo.com" <aryabinin@...tuozzo.com>,
        "afzal.mohd.ma@...il.com" <afzal.mohd.ma@...il.com>,
        "f.fainelli@...il.com" <f.fainelli@...il.com>,
        "labbott@...hat.com" <labbott@...hat.com>,
        "kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.com>,
        "mhocko@...e.com" <mhocko@...e.com>,
        "catalin.marinas@....com" <catalin.marinas@....com>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
        "mawilcox@...rosoft.com" <mawilcox@...rosoft.com>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "thgarnie@...gle.com" <thgarnie@...gle.com>,
        "keescook@...omium.org" <keescook@...omium.org>,
        "arnd@...db.de" <arnd@...db.de>,
        "vladimir.murzin@....com" <vladimir.murzin@....com>,
        "tixy@...aro.org" <tixy@...aro.org>,
        "ard.biesheuvel@...aro.org" <ard.biesheuvel@...aro.org>,
        "robin.murphy@....com" <robin.murphy@....com>,
        "mingo@...nel.org" <mingo@...nel.org>,
        "grygorii.strashko@...aro.org" <grygorii.strashko@...aro.org>,
        "glider@...gle.com" <glider@...gle.com>,
        "dvyukov@...gle.com" <dvyukov@...gle.com>,
        "opendmb@...il.com" <opendmb@...il.com>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "kasan-dev@...glegroups.com" <kasan-dev@...glegroups.com>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        Jiazhenghua <jiazhenghua@...wei.com>,
        Dailei <dylix.dailei@...wei.com>,
        Zengweilin <zengweilin@...wei.com>,
        Heshaoliang <heshaoliang@...wei.com>
Subject: Re: [PATCH 01/11] Initialize the mapping of KASan shadow memory

On Sat, 18 Nov 2017 10:40:08 +0000
"Liuwenliang (Abbott Liu)" <liuwenliang@...wei.com> wrote:

> On Nov 17, 2017  15:36 Christoffer Dall [mailto:cdall@...aro.org]  wrote:
> >If your processor does support LPAE (like a Cortex-A15 for example),
> >then you have both the 32-bit accessors (MRC and MCR) and the 64-bit
> >accessors (MRRC, MCRR), and using the 32-bit accessor will simply access
> >the lower 32-bits of the 64-bit register.
> >
> >Hope this helps,
> >-Christoffer  
> 
> If you know the higher 32-bits of the 64-bits cp15's register is not useful for your system,
> then you can use the 32-bit accessor to get or set the 64-bit cp15's register.
> But if the higher 32-bits of the 64-bits cp15's register is useful for your system,
> then you can't use the 32-bit accessor to get or set the 64-bit cp15's register.
> 
> TTBR0/TTBR1/PAR's higher 32-bits is useful for CPU supporting LPAE.
> The following description which comes from ARM(r) Architecture Reference
> Manual ARMv7-A and ARMv7-R edition tell us the reason:
> 
> 64-bit TTBR0 and TTBR1 format:
> ...
> BADDR, bits[39:x] : 
> Translation table base address, bits[39:x]. Defining the translation table base address width on
> page B4-1698 describes how x is defined.
> The value of x determines the required alignment of the translation table, which must be aligned to
> 2x bytes.
> 
> Abbott Liu: Because BADDR on CPU supporting LPAE may be bigger than max value of 32-bit, so bits[39:32] may 
> be valid value which is useful for the system.
> 
> 64-bit PAR format
> ...
> PA[39:12]
> Physical Address. The physical address corresponding to the supplied virtual address. This field
> returns address bits[39:12].
> 
> Abbott Liu: Because Physical Address on CPU supporting LPAE may be bigger than max value of 32-bit, 
> so bits[39:32] may be valid value which is useful for the system.
> 
> Conclusion: Don't use 32-bit accessor to get or set TTBR0/TTBR1/PAR on CPU supporting LPAE,
> if you do that, your system may run error.

That's not really true. You can run an non-LPAE kernel that uses the
32bit accessors an a Cortex-A15 that supports LPAE. You're just limited
to 4GB of physical space. And you're pretty much guaranteed to have
some memory below 4GB (one way or another), or you'd have a slight
problem setting up your page tables.

	M.
-- 
Without deviation from the norm, progress is not possible.