public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "ardb at kernel dot org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug target/102926] New: TLS register value is spilled to the stack instead of reloaded from the system register Date: Mon, 25 Oct 2021 11:35:14 +0000 [thread overview] Message-ID: <bug-102926-4@http.gcc.gnu.org/bugzilla/> (raw) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102926 Bug ID: 102926 Summary: TLS register value is spilled to the stack instead of reloaded from the system register Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: ardb at kernel dot org Target Milestone: --- Target: ARM The code below uses the hardware TLS register on ARM, and instead of reloading its value directly from the system register, it spills its value to the stack. This is suboptimal, and given that the TLS register is being proposed as an alternative reference for the stack protector canary, it is also a security concern, as an attacker that controls the stack may be able to control both sides of the equation in the stack protector check occurring at the end of the function. Instead, I would expect any subsequent uses of the thread pointer to simply issue the MRC again, which doesn't touch memory. $ cat /tmp/spill.c int foo(int); int bar(void) { int *l = __builtin_thread_pointer(); return foo(l[0]) + l[1]; } $ arm-linux-gnueabihf-gcc -o - -S /tmp/spill.c -O3 -mtp=cp15 -ffixed-r4 -ffixed-r5 -ffixed-r6 -ffixed-r7 -ffixed-r8 -ffixed-r9 -ffixed-r10 -fno-omit-frame-pointer .cpu arm10tdmi .arch armv5t .fpu softvfp .eabi_attribute 20, 1 .eabi_attribute 21, 1 .eabi_attribute 23, 3 .eabi_attribute 24, 1 .eabi_attribute 25, 1 .eabi_attribute 26, 2 .eabi_attribute 30, 2 .eabi_attribute 34, 0 .eabi_attribute 18, 4 .file "spill.c" .text .align 2 .global bar .syntax unified .arm .type bar, %function bar: @ args = 0, pretend = 0, frame = 8 @ frame_needed = 1, uses_anonymous_args = 0 push {fp, lr} add fp, sp, #4 sub sp, sp, #8 mrc p15, 0, r3, c13, c0, 3 @ load_tp_hard ldr r0, [r3] str r3, [fp, #-8] bl foo ldr r3, [fp, #-8] ldr r3, [r3, #4] add r0, r0, r3 sub sp, fp, #4 @ sp needed pop {fp, pc} .size bar, .-bar .ident "GCC: (GNU) 12.0.0 20211024 (experimental)" .section .note.GNU-stack,"",%progbits
next reply other threads:[~2021-10-25 11:35 UTC|newest] Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-10-25 11:35 ardb at kernel dot org [this message] 2021-10-25 11:50 ` [Bug target/102926] " pinskia at gcc dot gnu.org 2021-10-25 12:02 ` rguenth at gcc dot gnu.org 2021-10-25 12:03 ` ardb at kernel dot org 2021-10-25 12:12 ` pinskia at gcc dot gnu.org 2021-10-25 14:46 ` ardb at kernel dot org 2021-10-25 15:24 ` rsandifo at gcc dot gnu.org
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=bug-102926-4@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /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: linkBe 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).