linux-kernel - Re: [PATCH v1 1/3] arm64: add a macro for SError synchronization

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

Message-ID: <0184EA26B2509940AA629AE1405DD7F20193CD1C@DGGEMA503-MBX.china.huawei.com>
Date:   Wed, 1 Nov 2017 14:13:35 +0000
From:   gengdongjiu <gengdongjiu@...wei.com>
To:     Robin Murphy <robin.murphy@....com>,
        "catalin.marinas@....com" <catalin.marinas@....com>,
        "will.deacon@....com" <will.deacon@....com>,
        "marc.zyngier@....com" <marc.zyngier@....com>,
        "christoffer.dall@...aro.org" <christoffer.dall@...aro.org>,
        "james.morse@....com" <james.morse@....com>,
        "mark.rutland@....com" <mark.rutland@....com>,
        "ard.biesheuvel@...aro.org" <ard.biesheuvel@...aro.org>,
        "cov@...eaurora.org" <cov@...eaurora.org>,
        "Dave.Martin@....com" <Dave.Martin@....com>,
        "suzuki.poulose@....com" <suzuki.poulose@....com>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "kvmarm@...ts.cs.columbia.edu" <kvmarm@...ts.cs.columbia.edu>
Subject: Re: [PATCH v1 1/3] arm64: add a macro for SError synchronization

> 
> On 01/11/17 12:54, gengdongjiu wrote:
> > Hi Robin,
> >
> > On 2017/11/1 19:24, Robin Murphy wrote:
> >>> +	esb
> >>> +alternative_else_nop_endif
> >>> +1:
> >>> +	.endm
> >> Having a branch in here is pretty horrible, and furthermore using
> >> label number 1 has a pretty high chance of subtly breaking code where
> >> this macro is inserted.
> >>
> >> Can we not somehow nest or combine the alternative conditions here?
> >
> > I found it will report error if combine the alternative conditions here.
> >
> > For example:
> >
> > +	.macro	error_synchronize
> > +alternative_if ARM64_HAS_IESB
> > +alternative_if ARM64_HAS_RAS_EXTN
> > +	esb
> > +alternative_else_nop_endif
> > +alternative_else_nop_endif
> > +	.endm
> >
> > And even using b.eq/cbz instruction in the alternative instruction in
> > arch/arm64/kernel/entry.S, it will report Error.
> >
> > For example below
> >
> > alternative_if ARM64_HAS_PAN
> > 	xxxxxxxxxxxxxxxxxxxx
> >         b.eq    xxxxx
> > alternative_else_nop_endif
> >
> > I do not dig it deeply, do you know the reason about it or good suggestion about that?
> > Thanks a lot in advance.
> 
> Actually, on second look ARM64_HAS_RAS_EXTN doesn't even matter - ESB is a hint, so if the CPU doesn't have RAS it should behave as a
> NOP anyway.


Yes, you are right. It is "HINT #16"

So in fact it can be written below:

+       .macro  error_synchronize
+alternative_if_not ARM64_HAS_IESB
+       esb
+alternative_else_nop_endif
+       .endm

If written to that, whether it will be strange? although ESB should behave as a
NOP anyway if the CPU doesn't have RAS. 

> 
> On which note, since I don't see one here - are any of those other patches defining an "esb" assembly macro similar to the inline asm case?
> If not then this isn't going to build with older toolchains - perhaps we should just use the raw hint syntax directly.


Sorry for that I do not push the dependent patch[1].
The "ESB" is defined as a macro 

/*
+ * RAS Error Synchronization barrier
+ */
+	.macro  esb
+	hint    #16
+	.endm
+
+/*

[1]
https://www.spinics.net/lists/arm-kernel/msg612884.html

> 
> Robin.