[PATCH 002/120] MIPS: R5900: Trap the RDHWR instruction as an SQ address exception

[Fredrik Noring]

Hi Maciej,

On Thu, Nov 19, 2020 at 01:28:00PM +0000, Maciej W. Rozycki wrote:
>  The use of RDHWR, actual or emulated, is a part of the MIPS TLS psABI, 
> see: <https://www.linux-mips.org/wiki/NPTL>, in particular starting from: 
> <https://www.linux-mips.org/wiki/NPTL#Design_Choices> and throughout (the 
> expired certificate of the web site is a known issue, but there is 
> currently no way to get it fixed as nobody knows where Ralf Baechle has 
> gone).

Can the site be wrapped up and published elsewhere?

>  While there indeed is an unfortunate opcode overlap between RDHWR and SQ, 
> the encoding of the specific operands chosen for TLS pointer access is 
> luckily guaranteed to always trap in the user mode, because the address 
> requested when the encoding is interpreted as SQ rather than RDHWR is 
> within the kernel KSEG2 segment:
> 
> $ cat rdhwr.s
> 	rdhwr	$3, $29
> $ gcc -march=mips32r2 -c rdhwr.s
> $ objdump -d rdhwr.o
> rdhwr.o:     file format elf32-tradlittlemips
> 
> 
> Disassembly of section .text:
> 
> 00000000 <.text>:
>    0:	7c03e83b 	rdhwr	v1,$29
> 	...
> $ objdump -m mips:5900 -d rdhwr.o
> 
> rdhwr.o:     file format elf32-tradlittlemips
> 
> 
> Disassembly of section .text:
> 
> 00000000 <.text>:
>    0:	7c03e83b 	sq	v1,-6085(zero)
> 	...
> $ 
> 
> This is because the HWR read is encoded in bits 15:11 of the instruction 
> word and $29 has the highest bit set, which lands in bit 15 of the 
> instruction word, meaning that the offset encoded in bits 15:0 used where 
> the instruction word is interpreted as SQ is negative.  And then bits 
> 25:21 are hardwired to 0 in the encoding of RDHWR and they correspond to 
> the base register encoding with SQ, meaning that it will be interpreted as 
> $zero.  So the address ultimately requested is -6085 => 0xffffffffffffe83b 
> (the R5900 uses 32-bit addressing and ignores address bits 63:32, but that 
> does not matter here; this is KSEG2 either way).
> 
>  Consequently an AdES exception is triggered which we can trap and handle, 
> reinterpreting the encoding according to our needs and return the TLS 
> pointer in $v1 rather than issuing a SIGBUS.  So you are not expected to 
> see any issue unless there is a security erratum in the R5900 as well and 
> the encoding does not cause an exception for some reason.
> 
>  This of course disagrees with what Fredrik wrote in the quotation above, 
> as it's the last page rather than the zeroth that is accessed, but the net 
> effect is the same, or even better.

The first page could be mapped by the application itself, but what about
RDHWR registers $0-$3 having mnemonics CPUNum, SYNC1_Step, CC and CCRes[1],
or in Linux

/* RDHWR register numbers */
#define MIPS_HWR_CPUNUM		0	/* CPU number */
#define MIPS_HWR_SYNCISTEP	1	/* SYNCI step size */
#define MIPS_HWR_CC		2	/* Cycle counter */
#define MIPS_HWR_CCRES		3	/* Cycle counter resolution */
#define MIPS_HWR_ULR		29	/* UserLocal */
#define MIPS_HWR_IMPL1		30	/* Implementation dependent */
#define MIPS_HWR_IMPL2		31	/* Implementation dependent */

in arch/mips/include/asm/mipsregs.h? They land on the first page, no?

Fredrik

References:

[1] "MIPS Architecture for programmers Volume II-A: The MIPS32 Instruction
    Set", revision 5.04, 11 December 2013, p. 248.