linux-kernel - Re: [PATCH v4] 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] [day] [month] [year] [list]

Message-ID: <20190424073258.d5gv7s7ij5zujd2l@blommer>
Date:   Wed, 24 Apr 2019 08:33:01 +0100
From:   Mark Rutland <mark.rutland@....com>
To:     Kees Cook <keescook@...omium.org>
Cc:     Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will.deacon@....com>,
        Arnd Bergmann <arnd@...db.de>,
        Alex Matveev <alxmtvv@...il.com>,
        Ard Biesheuvel <ard.biesheuvel@...aro.org>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Yury Norov <ynorov@...iumnetworks.com>,
        Matthias Kaehlcke <mka@...omium.org>,
        Sami Tolvanen <samitolvanen@...gle.com>,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4] arm64: sysreg: Make mrs_s and msr_s macros work with
 Clang and LTO

Hi Kees,

On Tue, Apr 23, 2019 at 04:26:22PM -0700, Kees Cook wrote:
> Clang's integrated assembler does not allow assembly macros defined
> in one inline asm block using the .macro directive to be used across
> separate asm blocks. LLVM developers consider this a feature and not a
> bug, recommending code refactoring:
> 
>   https://bugs.llvm.org/show_bug.cgi?id=19749
> 
> As binutils doesn't allow macros to be redefined, this change uses
> UNDEFINE_MRS_S and UNDEFINE_MSR_S to define corresponding macros
> in-place and workaround gcc and clang limitations on redefining macros
> across different assembler blocks.

[...]

> diff --git a/arch/arm64/include/asm/irqflags.h b/arch/arm64/include/asm/irqflags.h
> index 43d8366c1e87..d359f28765cb 100644
> --- a/arch/arm64/include/asm/irqflags.h
> +++ b/arch/arm64/include/asm/irqflags.h
> @@ -43,7 +43,7 @@ static inline void arch_local_irq_enable(void)
>  	asm volatile(ALTERNATIVE(
>  		"msr	daifclr, #2		// arch_local_irq_enable\n"
>  		"nop",
> -		"msr_s  " __stringify(SYS_ICC_PMR_EL1) ",%0\n"
> +		__msr_s(SYS_ICC_PMR_EL1)

Seeing the __stringify() go is nice!

Our assembly happens to use argument 0 by coincidence rather than by deliberate
design, so please have the macro take the template, e.g.

	__msr_s(SYS_ICC_PMR_EL1, "%x0")

... that ways it's obvious as to which asm parameter is used, and this won't
complicate refactoring of the assembly (which may shuffle or rename the
parameters).

Likewise for __mrs_s(), e.g.

	__mrs_s("%x[va]", SYS_WHATEVER);

[...]

> +#define __mrs_s(r)						\
> +	DEFINE_MRS_S						\
> +"	mrs_s %0, " __stringify(r) "\n"				\
> +	UNDEFINE_MRS_S
> +
> +#define __msr_s(r)						\
> +	DEFINE_MSR_S						\
> +"	msr_s " __stringify(r) ", %0\n"				\
> +	UNDEFINE_MSR_S

These can be:

#define __mrs_s(v, r)						\
	DEFINE_MRS_S						\
"	mrs_s " v ", " __stringify(r) "\n"			\
	UNDEFINE_MRS_S


#define __msr_s(r, v)						\
	DEFINE_MSR_S						\
"	msr_s " __stringify(r) ", " v "\n"			\
	UNDEFINE_MSR_S


> +
> +/* For use with "rZ" constraints. */
> +#define __msr_s_x0(r)						\
> +	DEFINE_MSR_S						\
> +"	msr_s " __stringify(r) ", %x0\n"			\
> +	UNDEFINE_MSR_S

I don't think we need this. If we pass the template in, this is solved by the
caller, and we could consistently use the x form regardless.

Otherwise, I think this is as clean as we can make this short of bumping our
minimum binutils version and using the S<Op0>_<...> names.

Thanks,
Mark.