[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <add1937b-183b-17a9-94db-f384801a079e@marcan.st>
Date: Mon, 22 Feb 2021 00:20:11 +0900
From: Hector Martin <marcan@...can.st>
To: Mark Rutland <mark.rutland@....com>
Cc: linux-arm-kernel@...ts.infradead.org,
Marc Zyngier <maz@...nel.org>, Rob Herring <robh@...nel.org>,
Arnd Bergmann <arnd@...nel.org>,
Olof Johansson <olof@...om.net>,
Krzysztof Kozlowski <krzk@...nel.org>,
Mark Kettenis <mark.kettenis@...all.nl>,
Tony Lindgren <tony@...mide.com>,
Mohamed Mediouni <mohamed.mediouni@...amail.com>,
Stan Skowronek <stan@...ellium.com>,
Alexander Graf <graf@...zon.com>,
Will Deacon <will@...nel.org>,
Linus Walleij <linus.walleij@...aro.org>,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 00/25] Apple M1 SoC platform bring-up
On 18/02/2021 23.36, Mark Rutland wrote:
> IIUC, the CPUs in these parts have some IMP-DEF instructions that can be
> used at EL0 which might have some IMP-DEF state. Our general expectation
> is that FW should configure such things to trap, but I don't know
> whether the M1 FW does that, and I fear that this will end up being a
> problem for us -- even if that doesn't affect EL1/EL2, IMP-DEF state is
> an interesting covert channel between EL0 tasks, and not generally safe
> to use thanks to context-switch and idle, so I'd like to make sure we
> can catch usage and make it SIGILL.
>
> Do you happen to know whether all of that is configured to trap, and if
> not, is it possible to adjust the bootloader to ensure it is?
Very good point!
If only they were IMP-DEF... they're straight in Unallocated space. I
spent some time the other day exhaustively searching the chunk of the
encoding space where it looks like all these "fun" additions are,
at EL2, and I documented what I found here:
https://github.com/AsahiLinux/docs/wiki/HW:Apple-Instructions
I haven't tested things at EL0 yet, but it looks like the stateful
instructions known to be usable in EL0 (AMX) already default to trap on
this platform, so we should be safe there. Everything else looks like it
probably either shouldn't work in EL0 (I sure hope the address
translation one doesn't...) or is probably stateless. I'll dig deeper
and test EL0 in the future, but so far things look OK (for some
questionable values of OK :) ).
--
Hector Martin (marcan@...can.st)
Public Key: https://mrcn.st/pub
Powered by blists - more mailing lists