linux-kernel - Re: [PATCH v4 04/12] arm64: Basic Branch Target Identification support

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: <20200110182800.GI8786@arrakis.emea.arm.com>
Date:   Fri, 10 Jan 2020 18:28:00 +0000
From:   Catalin Marinas <catalin.marinas@....com>
To:     Mark Brown <broonie@...nel.org>
Cc:     Will Deacon <will@...nel.org>, Paul Elliott <paul.elliott@....com>,
        Peter Zijlstra <peterz@...radead.org>,
        Yu-cheng Yu <yu-cheng.yu@...el.com>,
        Amit Kachhap <amit.kachhap@....com>,
        Vincenzo Frascino <vincenzo.frascino@....com>,
        Marc Zyngier <maz@...nel.org>,
        Eugene Syromiatnikov <esyr@...hat.com>,
        Szabolcs Nagy <szabolcs.nagy@....com>,
        "H.J. Lu" <hjl.tools@...il.com>, Andrew Jones <drjones@...hat.com>,
        Kees Cook <keescook@...omium.org>,
        Arnd Bergmann <arnd@...db.de>, Jann Horn <jannh@...gle.com>,
        Richard Henderson <richard.henderson@...aro.org>,
        Kristina Martšenko <kristina.martsenko@....com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Florian Weimer <fweimer@...hat.com>,
        Sudakshina Das <sudi.das@....com>,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        linux-arch@...r.kernel.org, Dave Martin <Dave.Martin@....com>
Subject: Re: [PATCH v4 04/12] arm64: Basic Branch Target Identification
 support

On Wed, Dec 11, 2019 at 03:41:58PM +0000, Mark Brown wrote:
> diff --git a/arch/arm64/include/asm/ptrace.h b/arch/arm64/include/asm/ptrace.h
> index fbebb411ae20..212bba1f8d84 100644
> --- a/arch/arm64/include/asm/ptrace.h
> +++ b/arch/arm64/include/asm/ptrace.h
> @@ -35,8 +35,16 @@
>  #define GIC_PRIO_PSR_I_SET		(1 << 4)
>  
>  /* Additional SPSR bits not exposed in the UABI */
> +#define PSR_BTYPE_SHIFT		10
> +
>  #define PSR_IL_BIT		(1 << 20)
>  
> +/* Convenience names for the values of PSTATE.BTYPE */
> +#define PSR_BTYPE_NONE		(0b00 << PSR_BTYPE_SHIFT)
> +#define PSR_BTYPE_JC		(0b01 << PSR_BTYPE_SHIFT)
> +#define PSR_BTYPE_C		(0b10 << PSR_BTYPE_SHIFT)
> +#define PSR_BTYPE_J		(0b11 << PSR_BTYPE_SHIFT)

Would these be better placed in the uapi/ptrace.h?

> diff --git a/arch/arm64/kernel/syscall.c b/arch/arm64/kernel/syscall.c
> index 9a9d98a443fc..ef80ecbd6eaf 100644
> --- a/arch/arm64/kernel/syscall.c
> +++ b/arch/arm64/kernel/syscall.c
> @@ -98,6 +98,24 @@ static void el0_svc_common(struct pt_regs *regs, int scno, int sc_nr,
>  	regs->orig_x0 = regs->regs[0];
>  	regs->syscallno = scno;
>  
> +	/*
> +	 * BTI note:
> +	 * The architecture does not guarantee that SPSR.BTYPE is zero
> +	 * on taking an SVC, so we could return to userspace with a
> +	 * non-zero BTYPE after the syscall.

On page 2580 of the ARM ARM there is a statement that "any instruction
other than BR, ..." sets BTYPE to 0. Wouldn't SVC fall into the same
category?

> +	 *
> +	 * This shouldn't matter except when userspace is explicitly
> +	 * doing something stupid, such as setting PROT_BTI on a page
> +	 * that lacks conforming BTI/PACIxSP instructions, falling
> +	 * through from one executable page to another with differing
> +	 * PROT_BTI, or messing with BYTPE via ptrace: in such cases,

s/BYTPE/BTYPE/

Apart from the nitpicks above, the patch looks good to me:

Reviewed-by: Catalin Marinas <catalin.marinas@....com>