[RFC,v2,0/1] implement TLS register based stack canary for ARM
Message ID | 20211021165119.2136543-1-ardb@kernel.org |
---|---|
Headers |
Return-Path: <gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org> 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 6291F3857C70 for <patchwork@sourceware.org>; Thu, 21 Oct 2021 16:52:22 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6291F3857C70 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1634835142; bh=DJCO2QmiKimgH3sBSqsLvFQZ6aqA/z22Ut4TMOsXf7U=; h=To:Subject:Date:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:Cc:From; b=K2guNilGfv0eG6NR9iQeaDINeROLNJT5dMuyTAeJZ5GBRSPNUWYD5jAfyJ12Yk2fY bTj0ZQ2tqmEjaPpym+r5P4d7tAtG8zQtMQQwH2YknpAxBVfk66Xqj3DE9NYFCBQn8i LCfdPVUPFKyJ1Yhi2ltfpOI7TDzM4ecxMlmoENUg= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by sourceware.org (Postfix) with ESMTPS id 079683857810 for <gcc-patches@gcc.gnu.org>; Thu, 21 Oct 2021 16:51:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 079683857810 Received: by mail.kernel.org (Postfix) with ESMTPSA id E35966141B; Thu, 21 Oct 2021 16:51:34 +0000 (UTC) To: linux-hardening@vger.kernel.org Subject: [RFC PATCH v2 0/1] implement TLS register based stack canary for ARM Date: Thu, 21 Oct 2021 18:51:18 +0200 Message-Id: <20211021165119.2136543-1-ardb@kernel.org> X-Mailer: git-send-email 2.30.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.7 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 <gcc-patches.gcc.gnu.org> List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe> List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/> List-Post: <mailto:gcc-patches@gcc.gnu.org> List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help> List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe> From: Ard Biesheuvel via Gcc-patches <gcc-patches@gcc.gnu.org> Reply-To: Ard Biesheuvel <ardb@kernel.org> Cc: keescook@chromium.org, Richard Sandiford <richard.sandiford@arm.com>, thomas.preudhomme@celest.fr, Keith Packard <keithpac@amazon.com>, gcc-patches@gcc.gnu.org, Ard Biesheuvel <ardb@kernel.org> Errors-To: gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org Sender: "Gcc-patches" <gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org> |
Message
Ard Biesheuvel
Oct. 21, 2021, 4:51 p.m. UTC
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. As for the spilling issues that have been fixed in this code in the past: I suppose a register carrying the TLS register value will never get spilled to begin with? Comments/suggestions welcome. Cc: Keith Packard <keithpac@amazon.com> Cc: thomas.preudhomme@celest.fr Cc: adhemerval.zanella@linaro.org Cc: Qing Zhao <qing.zhao@oracle.com> Cc: Richard Sandiford <richard.sandiford@arm.com> 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.c | 52 ++++++++++++++++ gcc/config/arm/arm.md | 62 +++++++++++++++++++- gcc/config/arm/arm.opt | 22 +++++++ gcc/doc/invoke.texi | 9 +++ 6 files changed, 151 insertions(+), 2 deletions(-)