From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x633.google.com (mail-pl1-x633.google.com [IPv6:2607:f8b0:4864:20::633]) by sourceware.org (Postfix) with ESMTPS id 7FBFC3857803 for ; Thu, 21 Oct 2021 16:46:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7FBFC3857803 Received: by mail-pl1-x633.google.com with SMTP id g5so842808plg.1 for ; Thu, 21 Oct 2021 09:46:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=n/5EhXRYzMioZhTzwEt1B3sZlW7YU6BtPiTYhWArG08=; b=V3q+5CblfOUv8AWU8bQdzLU9DsubEQRW/m2LjBXcisqmDIg3U8+lWsfeBJkUaFSUrF VT+TDvpAtdH8VG92n4zuRV4juz+1DvPQ9DZRVW6dbyaXmEzpeB5MN5nu0Rdir3aDn+UE SMvlvUOlmv1LylQbKSXEbmSmLUVIrmVkWKtlRMXKxObNJjZysy8cjMaxcccYh13QcJWf Ts6YZ+fgjkGCxcUYC440GWrktWvO/lYR1WkEBMnoYrbg1yJlU2/bjdv8nqysdlQSO6pe SxLN4peLgz0iBUAcqEW9g4qsudYUkWVLz/lDzOkBc2xC37Azevhv3XD2CGA8kfcbDrty cZHw== X-Gm-Message-State: AOAM532eBWv2KU8HyXrEML/8AO+vDvWBl6loa0SFdcQBzT2QNSjHJWMl ppe8arj7i+7KsoPjyMMiXzzJ7A== X-Google-Smtp-Source: ABdhPJxT2BNah7vKDouchucml+EXV/m5bFi2FAXekbm5XOM62EWaYNswMYY4gXLbAVFZshH6xjV21w== X-Received: by 2002:a17:90b:4b90:: with SMTP id lr16mr4078908pjb.189.1634834774562; Thu, 21 Oct 2021 09:46:14 -0700 (PDT) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id 31sm4792895pgs.29.2021.10.21.09.46.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 21 Oct 2021 09:46:14 -0700 (PDT) Date: Thu, 21 Oct 2021 09:46:13 -0700 From: Kees Cook To: Ard Biesheuvel Cc: linux-hardening@vger.kernel.org, thomas.preudhomme@celest.fr, adhemerval.zanella@linaro.org, Qing Zhao , Richard Sandiford , gcc-patches@gcc.gnu.org, Keith Packard Subject: Re: [RFC PATCH 0/1] implement TLS register based stack canary for ARM Message-ID: <202110210944.D977EBD@keescook> References: <20211021102327.1415789-1-ardb@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, JMQ_SPF_NEUTRAL, KAM_SHORT, RCVD_IN_DNSWL_NONE, 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-List-Received-Date: Thu, 21 Oct 2021 16:46:17 -0000 On Thu, Oct 21, 2021 at 06:34:04PM +0200, Ard Biesheuvel wrote: > On Thu, 21 Oct 2021 at 12:23, Ard Biesheuvel wrote: > > > > 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. > > This is a lie LOL. > > > 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. > > > > ... and this is no longer true now that I fixed the correctness > problem. I will be sending out a v2 shortly, so please disregard this > one for now. Heh, I hadn't even had a chance to test it, so I'll hold off. :) Thanks! -Kees -- Kees Cook