Hi All

As per discussion over mailing list, we implemented workaround for AT speculative behaviour. If anybody interested they can look into the changes posted here: https://review.trustedfirmware.org/q/topic:%22at_errata_fix%22+(status:open%...) These changes are currently under review.

Thanks Manish Badarkhe

On 03/07/2020, 14:43, "TF-A on behalf of Soby Mathew via TF-A" <tf-a-bounces@lists.trustedfirmware.org on behalf of tf-a@lists.trustedfirmware.org> wrote:

> -----Original Message----- > From: Will Deacon willdeacon@google.com > Sent: 02 July 2020 15:47 > To: Soby Mathew Soby.Mathew@arm.com > Cc: Andrew Scull ascull@google.com; Raghu K > raghu.ncstate@icloud.com; android-kvm@google.com; Marc Zyngier > mzyngier@google.com; James Morse James.Morse@arm.com; tf- > a@lists.trustedfirmware.org > Subject: Re: [TF-A] Erroneous speculative AT workaround > > On Thu, Jul 02, 2020 at 02:15:47PM +0000, Soby Mathew wrote: > > So the fix as we currently understand would involve the following > > sequence > > : > > > > a. On Entry to EL3, save the incoming SCTLR_EL1.M and TCR_EL1.EPDx > bits and set them (ensure TCR_EL1.EPDx =1 prior to SCTLR_EL1.M =1 using > isb()) > > b. Prior to Exit from EL3, after the target context is restored, restore > the SCTLR_EL1.M and TCR_EL1.EPDx bits. > > > > The above sequence now means that any use of AT instruction targeted > > at lower EL from EL3 that require PTW will fault. So prior to use of > > AT, ensure the PTW are re-enabled and disabled back again after the AT > > instructions. > > > > If the above sequence is agreed upon to resolve the errata, then we > > can work on a patch for the same. I suspect current el1 register save > > and restore sequence in TF-A is a bit unwieldy and we may need to > > analyze all the entry points to EL3 to ensure we cover everything. > > Looks good to me, but there's still one niggle that I don't know how to solve. > If EL2 has been audited not to have any executable AT instructions, it may > not have a software workaround. However, if a secure interrupt is taken > from EL2 to EL3 while EL2 is the middle of a world switch, then there is a > small window where an AT instruction present at EL3 cold be speculatively > executed before you've had a chance to mess with SCTLR_EL1. > > Fun! Maybe it's worth documenting this somewhere?

Hi Will, Good point, this effectively means every EL2 software must implement the fix similar to KVM for this workaround to be effective (or else EL3 should also be audited to not to have any executable AT instruction). This needs to be communicated.

Since this is crossing TF-A boundary and need wider communication, I can initiate some internal discussion on how to communicate this properly.

Best Regards Soby Mathew

> > Will -- TF-A mailing list TF-A@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a