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.
