linux-kernel - Re: [PATCH v3] arm64: sysreg: make mrs_s and msr

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, 23 Apr 2019 15:12:40 +0100
From:   Mark Rutland <mark.rutland@....com>
To:     Nick Desaulniers <ndesaulniers@...gle.com>
Cc:     Arnd Bergmann <arnd@...db.de>, Kees Cook <keescook@...omium.org>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will.deacon@....com>,
        Alex Matveev <alxmtvv@...il.com>,
        Ard Biesheuvel <ard.biesheuvel@...aro.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Yury Norov <ynorov@...iumnetworks.com>,
        Matthias Kaehlcke <mka@...omium.org>,
        Sami Tolvanen <samitolvanen@...gle.com>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3] arm64: sysreg: make mrs_s and msr_s macros work with
 Clang and LTO

On Mon, Apr 22, 2019 at 10:44:10AM -0700, Nick Desaulniers wrote:
> On Tue, Apr 16, 2019 at 9:03 PM Kees Cook <keescook@...omium.org> wrote:
> >
> > On Tue, Apr 16, 2019 at 12:08 PM Mark Rutland <mark.rutland@....com> wrote:
> > >
> > > On Mon, Apr 15, 2019 at 10:22:27AM -0700, Nick Desaulniers wrote:
> > > > On Mon, Apr 15, 2019 at 10:06 AM Mark Rutland <mark.rutland@....com> wrote:
> > > > > It would be nice if we could simply rely on a more recent binutils these
> > > > > days, which supports the generic S<op0>_<op1>_<cn>_<Cm>_<op2> sysreg
> > > > > definition. That would mean we could get rid of the whole msr_s/mrs_s
> > > > > hack by turning that into a CPP macro which built that name.
> 
> Mark, can you give me a test case for this? I'd like to check if
> clang's integrated assembler supports this or not, so we can file an
> issue and fix it if not.

The below is a smoke test. The entire op0:op1:cn:cm:op2 space is 14
bits, so it should be feasible to generate and run an exhautive test for
all encodings.

I've included SYS and SYSL here too, since I strongly suspect we'll need
those going forward.

Thanks
Mark.

---->8----
/*
 * ${CC} -c test.c
 *
 * OLD_* encodings already exist, NEW_* encodings haven't yet be
 * allocated (per ARM DDI 0487D.a), but should assemble. All encodings
 * chosen arbitrarily.
 */

// OSDTRRX_EL1
#define OLD_DBG_REG	"s2_0_c0_c0_2"
#define NEW_DBG_REG	"s2_7_c0_c15_0"

// MIDR_EL1
#define OLD_SYS_REG	"s3_0_c0_c0_0"
#define NEW_SYS_REG	"s3_6_c1_c0_7"

#define REG(r)					\
	asm volatile("msr " r ", xzr\n");	\
	asm volatile("mrs xzr, " r "\n")

// DC IVAC, XZR
#define OLD_SYS	"#0, c7, c6, #1"
#define NEW_SYS "#7, c15, c15, #7"

#define NEW_SYSL_MIN	"#0, c0, c0, #0"
#define NEW_SYSL_MAX	"#7, c15, c15, #7"

#define SYS(s)	asm volatile("sys " s ", xzr\n")
#define SYSL(s)	asm volatile("sysl xzr, " s "\n")

void test(void)
{
	REG(OLD_DBG_REG);
	REG(NEW_DBG_REG);

	REG(OLD_SYS_REG);
	REG(NEW_SYS_REG);

	SYS(OLD_SYS);
	SYS(NEW_SYS);

	SYSL(NEW_SYSL_MIN);
	SYSL(NEW_SYSL_MAX);
}