From: Fredrik Noring <noring@nocrew.org>
To: "Maciej W. Rozycki" <macro@linux-mips.org>
Cc: "Philippe Mathieu-Daudé" <f4bug@amsat.org>,
linux-mips@vger.kernel.org, "Andreas Jaeger" <aj@suse.de>,
"Nick Clifton" <nickc@redhat.com>,
"Jürgen Urban" <JuergenUrban@gmx.de>,
libc-help@sourceware.org
Subject: Re: [PATCH 002/120] MIPS: R5900: Trap the RDHWR instruction as an SQ address exception
Date: Sat, 12 Dec 2020 11:58:38 +0100 [thread overview]
Message-ID: <X9SiXnZJLxDCrKMV@sx9> (raw)
In-Reply-To: <alpine.LFD.2.21.2011191241410.656242@eddie.linux-mips.org>
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.
next prev parent reply other threads:[~2020-12-12 10:58 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <cover.1567326213.git.noring@nocrew.org>
[not found] ` <4f856a5ea2c039c6639df875d11b5bff1bf7ecd2.1567326213.git.noring@nocrew.org>
2020-11-19 7:15 ` Philippe Mathieu-Daudé
2020-11-19 13:28 ` Maciej W. Rozycki
2020-11-19 13:42 ` Maciej W. Rozycki
2020-12-12 10:58 ` Fredrik Noring [this message]
2020-12-12 11:36 ` Maciej W. Rozycki
2020-12-12 12:14 ` Fredrik Noring
2020-12-13 11:43 ` Fredrik Noring
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=X9SiXnZJLxDCrKMV@sx9 \
--to=noring@nocrew.org \
--cc=JuergenUrban@gmx.de \
--cc=aj@suse.de \
--cc=f4bug@amsat.org \
--cc=libc-help@sourceware.org \
--cc=linux-mips@vger.kernel.org \
--cc=macro@linux-mips.org \
--cc=nickc@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).