> From: "Theo de Raadt" <[email protected]> > Date: Mon, 19 Oct 2020 09:25:30 -0600 > > Mark Kettenis <[email protected]> wrote: > > > > Date: Mon, 19 Oct 2020 16:36:14 +0200 > > > From: Christian Weisgerber <[email protected]> > > > > > > Belatedly, ARM has taken a slice of the reserved opcode space and > > > assigned it as a properly defined illegal instruction, udf #imm16. > > > (Armv8 Architecture Reference Manual, edition F.c, section C6.2.335). > > > Clang already knows about it. > > > > > > We really should use this instead of picking something ad-hoc out > > > of the opcode space. > > > > > > I have verified that this builds on arm64, produces a SIGILL in > > > userland, and drops me into ddb in the kernel. > > > > > > armv7 has an equivalent instruction. kettenis@ confirms it builds > > > and SIGILLs there. > > > > > > OK? > > > > So on armv7 there is an additional consideration. The architecture > > defines tow instruction sets: A32 and T32 (Thumb). A32 instructions > > are 32-bit but T32 instructions can be 16-bit. If an attacker can > > switch the CPU into T32 mode, it will interpret this UDF instruction > > as two different instructions. We may have to consider how "bad" > > these two instructions are and maybe tune that #imm16 accordingly. > > If the attacker has turned on thumb in the kernel I think all causes > are lost ... aren't there thousands of thumb gadgets?
Probably. So 0xa000f7f0 happens to be the 32-bit Thumb UDF instruction. If you jump into the middle of that you get an ADR instruction. SoI don't think that one was particularly "safe". So I think naddy's patch is fine.
