From patchwork Wed Jan 19 17:43:52 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ard Biesheuvel X-Patchwork-Id: 50244 Return-Path: X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 2DE623857C48 for ; Wed, 19 Jan 2022 17:45:31 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2DE623857C48 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1642614331; bh=Ctk+skkb4L4i01nrIJ1X5ZbKDShRQ5objsXF/SweuI4=; h=To:Subject:Date:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:Cc:From; b=nkQHHxTHqDGfuhhzt1e8QsVOoyJSvdw979HoCLSl+kSIQNlg9scUGG3JMSta8aHyq FusSncPt7aQTxLMVy9lGiWc87nJhPf0pWdIC1E/wvmUtsRZoU3j+DzERki5hOsQGik EyASJVf4IMHtc85Nt1ka0khfwQrhH3u9BwKZSq4c= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by sourceware.org (Postfix) with ESMTPS id 83DDC3858032 for ; Wed, 19 Jan 2022 17:44:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 83DDC3858032 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 13CB5B81A7A; Wed, 19 Jan 2022 17:44:10 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E698AC004E1; Wed, 19 Jan 2022 17:44:05 +0000 (UTC) To: linux-hardening@vger.kernel.org Subject: [PATCH v6 0/1] implement TLS register based stack canary for ARM Date: Wed, 19 Jan 2022 18:43:52 +0100 Message-Id: <20220119174353.213723-1-ardb@kernel.org> X-Mailer: git-send-email 2.30.2 MIME-Version: 1.0 X-Spam-Status: No, score=-5.6 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_SHORT, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Patchwork-Original-From: Ard Biesheuvel via Gcc-patches From: Ard Biesheuvel Reply-To: Ard Biesheuvel Cc: Richard Earnshaw , Richard Sandiford , thomas.preudhomme@celest.fr, Keith Packard , gcc-patches@gcc.gnu.org, Kyrylo Tkachov , Ard Biesheuvel Errors-To: gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org Sender: "Gcc-patches" Bugzilla: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102352 In the Linux kernel, user processes calling into the kernel are essentially threads running in the same address space, of a program that never terminates. This means that using a global variable for the stack protector canary value is problematic on SMP systems, as we can never change it unless we reboot the system. (Processes that sleep for any reason will do so on a call into the kernel, which means that there will always be live kernel stack frames carrying copies of the canary taken when the function was entered) AArch64 implements -mstack-protector-guard=sysreg for this purpose, as this permits the kernel to use different memory addresses for the stack canary for each CPU, and context switch the chosen system register with the rest of the process, allowing each process to use its own unique value for the stack canary. This patch implements something similar, but for the 32-bit ARM kernel, which will start using the user space TLS register TPIDRURO to index per-process metadata while running in the kernel. This means we can just add an offset to TPIDRURO to obtain the address from which to load the canary value. Changes since v5: - rebase onto latest changes, including .c -> .cc rename - ensure that tests execute only on targets that can support them Changes since v4: - add a couple of test cases - incorporate feedback received from Qing and Kyrylo Changes since v3: - force a reload of the TLS register before performing the stack protector check, so that we never rely on the stack for the address of the canary Changes since v2: - fix the template for stack_protect_test_tls so it correctly conveys the fact that it sets the Z flag Cc: Keith Packard Cc: thomas.preudhomme@celest.fr Cc: adhemerval.zanella@linaro.org Cc: Qing Zhao Cc: Richard Sandiford Cc: Kyrylo Tkachov Cc: Richard Earnshaw Cc: gcc-patches@gcc.gnu.org Ard Biesheuvel (1): [ARM] Add support for TLS register based stack protector canary access gcc/config/arm/arm-opts.h | 6 ++ gcc/config/arm/arm-protos.h | 2 + gcc/config/arm/arm.cc | 55 +++++++++++++++ gcc/config/arm/arm.md | 71 +++++++++++++++++++- gcc/config/arm/arm.opt | 22 ++++++ gcc/doc/invoke.texi | 11 +++ gcc/testsuite/gcc.target/arm/stack-protector-7.c | 12 ++++ gcc/testsuite/gcc.target/arm/stack-protector-8.c | 7 ++ 8 files changed, 184 insertions(+), 2 deletions(-) create mode 100644 gcc/testsuite/gcc.target/arm/stack-protector-7.c create mode 100644 gcc/testsuite/gcc.target/arm/stack-protector-8.c