On Wed, Oct 02, 2024 at 08:29:28PM +0100, Marc Zyngier wrote:
Mark Brown broonie@kernel.org wrote:
They are, though really they should UNDEF if GCS isn't there (which I had thought was what you were referencing here). Equally we only have traps for a subset of GCS instructions and it's not like there aren't a whole bunch of untrappable extensions anyway so it's not clear it's worth the effort just for that.
If the encodings UNDEF when GCS is not implemented (i.e. they are not in the NOP space), then all trapable instructions should absolutely UNDEF (and yes, it is worth the effort, even if it is only to demonstrate that the architecture is sub-par).
Yes, see DDI0487 K.a C5.9. If you're concerned about being unable to generate UNDEFs there's a rather large set of existing extensions where that's not possible, most of the hwcaps in the hwcap selftest that don't set sigill_reliable but do have a SIGILL generator for a start.
So I expect the next version to handle traps for GCSPUSHX, GCSPOPX, GCSPUSHM, GCSSTR and GCSSTTR when GCS isn't enabled.
OK, I already had that change locally after your first message.
I'm also pretty sure this is missing some form of sanitisation for PSTATE.EXLOCK, and looking at the pseudocode, you seem to be missing the handling of that bit on exception injection.
Ah, yes - I think I see the missing exception injection handling in enter_exception64(). I'm not seeing what you're referencing with sanitisation though, could you give me some more specific pointers please?