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

Message-ID: <20171121122938.sydii3i36jbzi7x4@lakrids.cambridge.arm.com>
Date:   Tue, 21 Nov 2017 12:29:38 +0000
From:   Mark Rutland <mark.rutland@....com>
To:     "Liuwenliang (Abbott Liu)" <liuwenliang@...wei.com>
Cc:     Marc Zyngier <marc.zyngier@....com>,
        "tixy@...aro.org" <tixy@...aro.org>,
        "mhocko@...e.com" <mhocko@...e.com>,
        "grygorii.strashko@...aro.org" <grygorii.strashko@...aro.org>,
        "catalin.marinas@....com" <catalin.marinas@....com>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        "glider@...gle.com" <glider@...gle.com>,
        "afzal.mohd.ma@...il.com" <afzal.mohd.ma@...il.com>,
        "mingo@...nel.org" <mingo@...nel.org>,
        Christoffer Dall <cdall@...aro.org>,
        "f.fainelli@...il.com" <f.fainelli@...il.com>,
        "mawilcox@...rosoft.com" <mawilcox@...rosoft.com>,
        "linux@...linux.org.uk" <linux@...linux.org.uk>,
        "kasan-dev@...glegroups.com" <kasan-dev@...glegroups.com>,
        Dailei <dylix.dailei@...wei.com>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "aryabinin@...tuozzo.com" <aryabinin@...tuozzo.com>,
        "labbott@...hat.com" <labbott@...hat.com>,
        "vladimir.murzin@....com" <vladimir.murzin@....com>,
        "keescook@...omium.org" <keescook@...omium.org>,
        "arnd@...db.de" <arnd@...db.de>,
        Zengweilin <zengweilin@...wei.com>,
        "opendmb@...il.com" <opendmb@...il.com>,
        Heshaoliang <heshaoliang@...wei.com>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "dvyukov@...gle.com" <dvyukov@...gle.com>,
        "ard.biesheuvel@...aro.org" <ard.biesheuvel@...aro.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Jiazhenghua <jiazhenghua@...wei.com>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
        "robin.murphy@....com" <robin.murphy@....com>,
        "thgarnie@...gle.com" <thgarnie@...gle.com>,
        "kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.com>
Subject: Re: 答复: [PATCH 01/11] Initialize
 the mapping of KASan shadow memory

On Tue, Nov 21, 2017 at 07:59:01AM +0000, Liuwenliang (Abbott Liu) wrote:
> On Nov 17, 2017  21:49  Marc Zyngier [mailto:marc.zyngier@....com]  wrote:
> >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:

> Please don't ask people to limit to 4GB of physical space on CPU
> supporting LPAE, please don't ask people to guaranteed to have some
> memory below 4GB on CPU supporting LPAE.

I don't think that Marc is suggesting that you'd always use the 32-bit
accessors on an LPAE system, just that all the definitions should exist
regardless of configuration.

So rather than this:

> +#ifdef CONFIG_ARM_LPAE
> +#define TTBR0           __ACCESS_CP15_64(0, c2)
> +#define TTBR1           __ACCESS_CP15_64(1, c2)
> +#define PAR             __ACCESS_CP15_64(0, c7)
> +#else
> +#define TTBR0           __ACCESS_CP15(c2, 0, c0, 0)
> +#define TTBR1           __ACCESS_CP15(c2, 0, c0, 1)
> +#define PAR             __ACCESS_CP15(c7, 0, c4, 0)
> +#endif

... you'd have the following in cp15.h:

#define TTBR0_64	__ACCESS_CP15_64(0, c2)
#define TTBR1_64	__ACCESS_CP15_64(1, c2)
#define PAR_64		__ACCESS_CP15_64(0, c7)

#define TTBR0_32	__ACCESS_CP15(c2, 0, c0, 0)
#define TTBR1_32	__ACCESS_CP15(c2, 0, c0, 1)
#define PAR_32		__ACCESS_CP15(c7, 0, c4, 0)

... and elsewhere, where it matters, we choose which to use depending on
the kernel configuration, e.g.

void set_ttbr0(u64 val)
{
	if (IS_ENABLED(CONFIG_ARM_LPAE))
		write_sysreg(val, TTBR0_64);
	else
		write_sysreg(val, TTBR0_32);
}

Thanks,
Mark.