Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp945024ybz; Wed, 22 Apr 2020 10:41:33 -0700 (PDT) X-Google-Smtp-Source: APiQypK3ebUP06wHr5ID5k2QmxOJOY32G/p2lZ0fY1kCCBAInSPrBifYkSBTIbpRGW/Gee4xLMux X-Received: by 2002:a50:951c:: with SMTP id u28mr23264278eda.310.1587577293780; Wed, 22 Apr 2020 10:41:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1587577293; cv=none; d=google.com; s=arc-20160816; b=F5UxoQjcDzxEhh4RIEEqQ4xm8MMsHgEqpxBs7+rAT/oUP5FBARwfBSXG1I+b07lKM9 vBAHtBUdpVAYUWABl/TKNhnlSIA0T9B1yQMNMO9D+GKw2YtmLWvaoMt7z7JllK+8S8fx umkRCyD+bO4a5VxbWcO1rP3uNgP3fkzb/m0OjZNcTkAyJQGKjZn51Jjy+vLphPaGKkqI q0axqd6wWL45OY0wouHXznFF/vB3bSO3Vp2Qfs9+QQatH9CprCO9H3++CwHWa9WL5npU dxoYL+GLvp/OMLbzMqejUD4fHZ+QMzGkhAx98FpDvex1BsddMyFdrb60sPuCU/WD6idV 45kQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=ZknEWD7Qqh3LI5XAbWu2EBkpENB2rMhY+1NM2mH6y4M=; b=Ct0OipEy1xkIh+nEWq6crqlqqwHdup9XEC+eH7OaY4FfA0zp4AJzBsXmf3a8wcACqJ 6g17FBxAjrGZlETKpyr1BnyMeNtgBvJ1gCjNe060/Pl0UIsc+wR2tm221nPrPY0BQp7b 5l6jWILS70wzyMgdJebIAL+xfMZHWlMcux8ex2NDUw4lUKXUWMajO9FYpREYtW+7Z+Qh ueMb2Eij3/3HMCEsPO/mfOi8o4p471MEFa3YPTuUpNAaCnLOUuFvNGrejUMJaABRuDmk GQlbipXxDOdaYkx/AcIHO+jTrc2kVo12akzLnmHMR/Ke4JWgCOnwfhgIyVZhHzWvQYVU nGhw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=JyusGuPT; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id s4si3837736ejq.495.2020.04.22.10.41.10; Wed, 22 Apr 2020 10:41:33 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=JyusGuPT; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726181AbgDVRj4 (ORCPT + 99 others); Wed, 22 Apr 2020 13:39:56 -0400 Received: from mail.kernel.org ([198.145.29.99]:47250 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726061AbgDVRjz (ORCPT ); Wed, 22 Apr 2020 13:39:55 -0400 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 54D942076E; Wed, 22 Apr 2020 17:39:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1587577195; bh=AGiU7qjKR7ZjubwJ6K3M5/8GasoseXdg8O+47fVqLuw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=JyusGuPT4yl7OaJxaidjSDJ0k/CikIy6bBfxMY0e+Pl8R0Jyo0kh0xtn6x5NZmkJc 57TrOndBtCukynqsiQxqbtjZ/p4Kv1jhveVyOIXjcX+v2OQKZhsYeb5Uw/OHmxFOIs 4BB1KgVHdsNjWZXGTusGX+5UGalpUEJglG0CFtsA= Date: Wed, 22 Apr 2020 18:39:47 +0100 From: Will Deacon To: Sami Tolvanen Cc: Catalin Marinas , James Morse , Steven Rostedt , Ard Biesheuvel , Mark Rutland , Masahiro Yamada , Michal Marek , Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dave Martin , Kees Cook , Laura Abbott , Marc Zyngier , Masami Hiramatsu , Nick Desaulniers , Jann Horn , Miguel Ojeda , clang-built-linux@googlegroups.com, kernel-hardening@lists.openwall.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v11 01/12] add support for Clang's Shadow Call Stack (SCS) Message-ID: <20200422173938.GA3069@willie-the-truck> References: <20191018161033.261971-1-samitolvanen@google.com> <20200416161245.148813-1-samitolvanen@google.com> <20200416161245.148813-2-samitolvanen@google.com> <20200420171727.GB24386@willie-the-truck> <20200420211830.GA5081@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200420211830.GA5081@google.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Apr 20, 2020 at 02:18:30PM -0700, Sami Tolvanen wrote: > On Mon, Apr 20, 2020 at 06:17:28PM +0100, Will Deacon wrote: > > > + * The shadow call stack is aligned to SCS_SIZE, and grows > > > + * upwards, so we can mask out the low bits to extract the base > > > + * when the task is not running. > > > + */ > > > + return (void *)((unsigned long)task_scs(tsk) & ~(SCS_SIZE - 1)); > > > > Could we avoid forcing this alignment it we stored the SCS pointer as a > > (base,offset) pair instead? That might be friendlier on the allocations > > later on. > > The idea is to avoid storing the current task's shadow stack address in > memory, which is why I would rather not store the base address either. What I mean is that, instead of storing the current shadow stack pointer, we instead store a base and an offset. We can still clear the base, as you do with the pointer today, and I don't see that the offset is useful to an attacker on its own. But more generally, is it really worthwhile to do this clearing at all? Can you (or Kees?) provide some justification for it, please? We don't do it for anything else, e.g. the pointer authentication keys, so something feels amiss here. Thanks, Will