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]

Date:   Mon, 13 Jan 2020 14:00:51 +0000
From:   Mark Brown <broonie@...nel.org>
To:     Catalin Marinas <catalin.marinas@....com>
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 Fri, Jan 10, 2020 at 06:28:00PM +0000, Catalin Marinas wrote:
> On Wed, Dec 11, 2019 at 03:41:58PM +0000, Mark Brown wrote:

> >  /* 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?

Seems reasonable, they might be useful to virt stuff and they're
part of the architecture so it's not like we might change them.

> > +	/*
> > +	 * 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?

I think what Dave was referring to there is that (unless I'm
misreading things) that section of the ARM says that BTYPE is set
at the end of the execution of the instruction but since SVC is
specified as generating an exception that means that when we
enter the kernel the instruction won't have ended yet and we
still have the BTYPE from the previous instruction.

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

Thanks.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)