linux-kernel - Re: [PATCH v4] arm64: Add support for new control bits CTR_EL0.DIC and CTR

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:   Thu, 22 Feb 2018 16:33:30 +0000
From:   Mark Rutland <mark.rutland@....com>
To:     Robin Murphy <robin.murphy@....com>
Cc:     Shanker Donthineni <shankerd@...eaurora.org>,
        Philip Elcan <pelcan@...eaurora.org>,
        Marc Zyngier <marc.zyngier@....com>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will.deacon@....com>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        kvmarm <kvmarm@...ts.cs.columbia.edu>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v4] arm64: Add support for new control bits CTR_EL0.DIC
 and CTR_EL0.IDC

On Thu, Feb 22, 2018 at 04:28:03PM +0000, Robin Murphy wrote:
> [Apologies to keep elbowing in, and if I'm being thick here...]
> 
> On 22/02/18 15:22, Mark Rutland wrote:
> > On Thu, Feb 22, 2018 at 08:51:30AM -0600, Shanker Donthineni wrote:
> > > +#define CTR_B31_SHIFT		31
> > 
> > Since this is just a RES1 bit, I think we don't need a mnemonic for it,
> > but I'll defer to Will and Catalin on that.
> > 
> > >   ENTRY(invalidate_icache_range)
> > > +#ifdef CONFIG_ARM64_SKIP_CACHE_POU
> > > +alternative_if ARM64_HAS_CACHE_DIC
> > > +	mov	x0, xzr
> > > +	dsb	ishst
> > > +	isb
> > > +	ret
> > > +alternative_else_nop_endif
> > > +#endif
> > 
> > As commented on v3, I don't believe you need the DSB here. If prior
> > stores haven't been completed at this point, the existing implementation
> > would not work correctly here.
> 
> True in terms of ordering between stores prior to entry and the IC IVAU
> itself, but what about the DSH ISH currently issued *after* the IC IVAU
> before returning? Is provably impossible that existing callers might be
> relying on that ordering *anything*, or would we risk losing something
> subtle by effectively removing it?

AFAIK, the only caller of this is KVM, before page table updates occur
to add execute permissions to the page this is applied to.

At least in that case, I do not beleive there would be breakage.

If we're worried about subtleties in callers, then we'd need to stick
with DSB ISH rather than optimising to DSH ISHST.

Thanks,
Mark.