From patchwork Thu Oct 21 10:23:26 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ard Biesheuvel X-Patchwork-Id: 1544274 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: bilbo.ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.a=rsa-sha256 header.s=default header.b=blabailT; dkim-atps=neutral Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org (client-ip=2620:52:3:1:0:246e:9693:128c; helo=sourceware.org; envelope-from=gcc-patches-bounces+incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=) Received: from sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by bilbo.ozlabs.org (Postfix) with ESMTPS id 4HZk9w1Zqwz9sWJ for ; Thu, 21 Oct 2021 21:24:36 +1100 (AEDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 1E0473858416 for ; Thu, 21 Oct 2021 10:24:34 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1E0473858416 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1634811874; bh=o1eyQE+OcKuJus4mOo1A7l8pO8GRgK6ZOVBOEFV+i0M=; h=To:Subject:Date:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:Cc:From; b=blabailTEQWfQ9lAE3yCSjAu/cJW1/0hnTL6cKegYmufl1Q+6FIdmVBkQeNQoLVN5 t7bU4xNwPVkvHEvb51568wTv90Tis42apJszN0FL5vVXVggS7G79BL7eWkvlhBbR9V FIJSJm79Zmjur6YG/NmqU4YiavHzsDU5EocdN1Do= 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 A546E3858D39 for ; Thu, 21 Oct 2021 10:23:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A546E3858D39 Received: by mail.kernel.org (Postfix) with ESMTPSA id C9AFF60F6E; Thu, 21 Oct 2021 10:23:47 +0000 (UTC) To: linux-hardening@vger.kernel.org Subject: [RFC PATCH 0/1] implement TLS register based stack canary for ARM Date: Thu, 21 Oct 2021 12:23:26 +0200 Message-Id: <20211021102327.1415789-1-ardb@kernel.org> X-Mailer: git-send-email 2.30.2 MIME-Version: 1.0 X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_SHORT, SCC_5_SHORT_WORD_LINES, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no 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: keescook@chromium.org, Richard Sandiford , thomas.preudhomme@celest.fr, gcc-patches@gcc.gnu.org, Ard Biesheuvel Errors-To: gcc-patches-bounces+incoming=patchwork.ozlabs.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. The patch is a bit rough around the edges, but produces the correct results as far as I can tell. However, I couldn't quite figure out how to modify the patterns so that the offset will be moved into the immediate offset field of the LDR instructions, so currently, the ADD of the offset is always a distinct instruction. 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? How about a register that carries TLS+? Comments/suggestions welcome. Cc: thomas.preudhomme@celest.fr Cc: adhemerval.zanella@linaro.org Cc: Qing Zhao Cc: Richard Sandiford 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.c | 39 +++++++++++++++++ gcc/config/arm/arm.md | 44 ++++++++++++++++++-- gcc/config/arm/arm.opt | 22 ++++++++++ gcc/doc/invoke.texi | 9 ++++ 5 files changed, 116 insertions(+), 4 deletions(-)