From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ste-pvt-msa1.bahnhof.se (ste-pvt-msa1.bahnhof.se [213.80.101.70]) by sourceware.org (Postfix) with ESMTPS id DDBB73854804 for ; Sat, 12 Dec 2020 10:58:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org DDBB73854804 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=nocrew.org Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=noring@nocrew.org Received: from localhost (localhost [127.0.0.1]) by ste-pvt-msa1.bahnhof.se (Postfix) with ESMTP id 97ABE3F896; Sat, 12 Dec 2020 11:58:40 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at bahnhof.se X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_SOFTFAIL autolearn=no autolearn_force=no version=3.4.2 Received: from ste-pvt-msa1.bahnhof.se ([127.0.0.1]) by localhost (ste-pvt-msa1.bahnhof.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ze8OC6IahE9v; Sat, 12 Dec 2020 11:58:39 +0100 (CET) Received: by ste-pvt-msa1.bahnhof.se (Postfix) with ESMTPA id AA62B3F61B; Sat, 12 Dec 2020 11:58:38 +0100 (CET) Date: Sat, 12 Dec 2020 11:58:38 +0100 From: Fredrik Noring To: "Maciej W. Rozycki" Cc: Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= , linux-mips@vger.kernel.org, Andreas Jaeger , Nick Clifton , =?utf-8?Q?J=C3=BCrgen?= Urban , libc-help@sourceware.org Subject: Re: [PATCH 002/120] MIPS: R5900: Trap the RDHWR instruction as an SQ address exception Message-ID: References: <4f856a5ea2c039c6639df875d11b5bff1bf7ecd2.1567326213.git.noring@nocrew.org> <2767f5c3-4e89-6543-34f7-6cd1a1be8c23@amsat.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-help@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-help mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Dec 2020 10:58:43 -0000 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: , in particular starting from: > 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.