From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 660C8C2BA1A for ; Fri, 24 Apr 2020 10:12:43 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 308E92087E for ; Fri, 24 Apr 2020 10:12:43 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="lfSuHb0d"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="kSbPHK0w" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 308E92087E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=2kPNxOccGPWBa0trwagMzEOcX+cL3xNW0dqli8vXjI4=; b=lfSuHb0dgX0gq1 tsQxNAy6WAnF59BmgRWvNoKEC0u+/gNRt9m6M9EFQGDaHKBiDig29xa9BjeZCBSHb0W+HXRTCRJ6W O3x6zgiCcPOvZHaxPxuD71LC/5/RKVJzQsDtQSVAQpTDX9Jv2Wws0SzNY3GUdpyiybMjXdOj/gxD2 7ev3AwJ86G6UnubTsYBdArSXAVLhVIAiYXDFp/q8J8RPGUzoGoQKanwhLziq9OxWqRGI2+eveUuN9 0BVAM5Ie5I8YvlErgXk5vjY50P7+x0aDbj4YqxM2w5JKth/d1eD2FTKmS41h6llR3a0FPT23efGdb fkzOiwx7m7Ijcayizqpg==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jRvK5-0004nV-9z; Fri, 24 Apr 2020 10:12:41 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jRvK3-0004kt-0I for linux-arm-kernel@lists.infradead.org; Fri, 24 Apr 2020 10:12:40 +0000 Received: from willie-the-truck (236.31.169.217.in-addr.arpa [217.169.31.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 92E232071E; Fri, 24 Apr 2020 10:12:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1587723158; bh=fKU2iKdaO5V4T6aQoOLQEGsSBw4yYPCuYH7VaMC/eI4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=kSbPHK0wqHUeZAx9aecwnpy9ShuMSbMzEpsNdzkiRkR+RFN1VJhrAPY0PtUxIniT/ /wGBoKmysJ8CLXyd8f+lLlmKyEC4ej+hXUEjlSAbRI/eBWZ8LXlTour55sGrZaQ3Fm Ed1oqAak/yYVJ2wRfjZdMUjAgrADXoM7Kob9i6ME= Date: Fri, 24 Apr 2020 11:12:31 +0100 From: Will Deacon To: Kees Cook Subject: Re: [PATCH v12 01/12] add support for Clang's Shadow Call Stack (SCS) Message-ID: <20200424101230.GB21141@willie-the-truck> References: <20191018161033.261971-1-samitolvanen@google.com> <20200421021453.198187-1-samitolvanen@google.com> <20200421021453.198187-2-samitolvanen@google.com> <202004221052.489CCFEBC@keescook> <20200422180040.GC3121@willie-the-truck> <202004231108.1AC704F609@keescook> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <202004231108.1AC704F609@keescook> User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200424_031239_060596_2F5293DA X-CRM114-Status: GOOD ( 16.97 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , Juri Lelli , kernel-hardening@lists.openwall.com, Peter Zijlstra , Catalin Marinas , Marc Zyngier , Masahiro Yamada , clang-built-linux@googlegroups.com, Ingo Molnar , Sami Tolvanen , Laura Abbott , Dave Martin , Jann Horn , Steven Rostedt , linux-arm-kernel@lists.infradead.org, Michal Marek , Ard Biesheuvel , Nick Desaulniers , linux-kernel@vger.kernel.org, Miguel Ojeda , James Morse , Masami Hiramatsu Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Apr 23, 2020 at 11:09:24AM -0700, Kees Cook wrote: > On Wed, Apr 22, 2020 at 07:00:40PM +0100, Will Deacon wrote: > > On Wed, Apr 22, 2020 at 10:54:45AM -0700, Kees Cook wrote: > > > On Mon, Apr 20, 2020 at 07:14:42PM -0700, Sami Tolvanen wrote: > > > > +void scs_release(struct task_struct *tsk) > > > > +{ > > > > + void *s; > > > > + > > > > + s = __scs_base(tsk); > > > > + if (!s) > > > > + return; > > > > + > > > > + WARN_ON(scs_corrupted(tsk)); > > > > + > > > > > > I'd like to have task_set_scs(tsk, NULL) retained here, to avoid need to > > > depend on the released task memory getting scrubbed at a later time. > > > > Hmm, doesn't it get zeroed almost immediately by kmem_cache_free() if > > INIT_ON_FREE_DEFAULT_ON is set? That seems much better than special-casing > > SCS, as there's a tonne of other useful stuff kicking around in the > > task_struct and treating this specially feels odd to me. > > That's going to be an uncommon config except for the most paranoid of > system builders. :) Sounds like a perfect fit, then ;) > Having this get wiped particular thing wiped is just > a decent best practice for what is otherwise treated as a "secret", just > like crypto routines wipe their secrets before free(). Sorry, but I don't buy that analogy. The SCS pointer is stored in memory all over the place and if it needs to treated in the same way as crypto secrets then this whole thing needs rethinking. On top of that, where crypto routines may wipe their secrets, we don't do what is being proposed for the SCS pointer to other similar pieces of data, such as pointer authentication keys. Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel