Hi,
I guess I'm late for the party. But I have some questions. Looking at the initial email from Andrew, these two points stood out.
--8<-- 1. Whilst looking at the speculative AT workaround in KVM, I compared it against the workaround in TF-A and noticed an inconsistency whereby TF-A **breaks** KVM's workaround. 2. TF-A will also have to be compatible with whatever workaround the EL2 software is using -->8--
Some questions about the unwanted dependency that this fix in TF-A creates.
1. Does KVM team always announce all the dependencies, along with their version numbers, that consumers should use? 2. With the fix in TF-A, are we forcing consumers to upgrade their TF-A blobs? Is this normal practice for consumers? 3. How do we plan to make the upgrade from TF-A side easier? Runtime detection of the feature (similar to the Spectre and Meltdown fixes) comes to mind.
-Varun
-----Original Message----- From: TF-A tf-a-bounces@lists.trustedfirmware.org On Behalf Of Manish Badarkhe via TF-A Sent: Thursday, July 30, 2020 10:48 PM To: tf-a@lists.trustedfirmware.org Cc: Will Deacon willdeacon@google.com; android-kvm@google.com; Marc Zyngier mzyngier@google.com; James Morse James.Morse@arm.com; Andrew Scull ascull@google.com Subject: Re: [TF-A] Erroneous speculative AT workaround
External email: Use caution opening links or attachments
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
-- TF-A mailing list TF-A@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a