Received: by 2002:a25:d7c1:0:0:0:0:0 with SMTP id o184csp5868490ybg; Tue, 22 Oct 2019 09:31:07 -0700 (PDT) X-Google-Smtp-Source: APXvYqzjpIeSbjTgjglq1KetVo1p0TI5oCLxSAk8GaHwYg74HQOM8W9P2Q1fTCsm3cskl3YzXUpW X-Received: by 2002:a50:fc86:: with SMTP id f6mr32354781edq.233.1571761867210; Tue, 22 Oct 2019 09:31:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1571761867; cv=none; d=google.com; s=arc-20160816; b=YpYKo3+W2fK5WHrAFEi4nDYfIT5Fod2cJTVGBwjaHB/So5XiJHIC/Cijbhlld+wn4h aI0Ba5qDXfjd2vDxxpGGkedPli+wDd9LwJ9pTmJnt/+Xj7tAAKXRoifL2PVd/jRwqxTS JcTbw/anVOYMwhGFGTB3PVfc9u1e+wK1T0cdtDw6/HoprfSykN808kfqiUgWiNntI+Fc 97B6pg2LpCBrhYz/nHxBss+X3Mkp2UF0/7i39NUWDwiGTMhLZetMYrJtdivnKGuxXwIk KX+omGpYFh9c4aTL6oFYJyKNMAco5mO4/tw0zYt9OUzs08OEOrXDIUaSP5rmjgNHEin4 Yhdg== 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; bh=bVXzkQQS/M5myuo+9rMPAg111c6jVV8u89+DVmZfmJg=; b=F2y7BOEjOvGOMtPevzhCOONEQNFbyU/+7xruMgWzeHt9g15zVVQI3/GOI4KeL7V0tL orJWePC3jGDuKIR5WCC2+/UJIZTjyIDCnDYMk/n296tRtOw28f7W25jWXrPkLVx9cOOb sGn4okn08CQWB25+XUuHG7XgL7kbYLpYrplJTE9DAbLbKYJ1eduZnYOeyZQaWQyrT3e0 VJxANs2lDlYZxxF1ZzxvklHGf9UDuhEMl0udrRDyDlF6PG6tJdxYCp/V5drEVXpx1zss M251jip1G6P4UhHpkTkZvA8Eb0fiJUD/QIBjj1ljH9HnwIY0KVZF7vyBWejw5j4+rkKg Wb/w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u3si10515639ejj.47.2019.10.22.09.30.42; Tue, 22 Oct 2019 09:31:07 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388700AbfJVQAk (ORCPT + 99 others); Tue, 22 Oct 2019 12:00:40 -0400 Received: from [217.140.110.172] ([217.140.110.172]:56130 "EHLO foss.arm.com" rhost-flags-FAIL-FAIL-OK-OK) by vger.kernel.org with ESMTP id S2387746AbfJVQAj (ORCPT ); Tue, 22 Oct 2019 12:00:39 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id B6C2C177F; Tue, 22 Oct 2019 09:00:14 -0700 (PDT) Received: from lakrids.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 09A513F71A; Tue, 22 Oct 2019 09:00:12 -0700 (PDT) Date: Tue, 22 Oct 2019 17:00:10 +0100 From: Mark Rutland To: Nick Desaulniers Cc: Sami Tolvanen , Will Deacon , Catalin Marinas , Steven Rostedt , Ard Biesheuvel , Dave Martin , Kees Cook , Laura Abbott , clang-built-linux , Kernel Hardening , Linux ARM , LKML Subject: Re: [PATCH 12/18] arm64: reserve x18 only with Shadow Call Stack Message-ID: <20191022160010.GB699@lakrids.cambridge.arm.com> References: <20191018161033.261971-1-samitolvanen@google.com> <20191018161033.261971-13-samitolvanen@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.1+11 (2f07cb52) (2018-12-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Oct 18, 2019 at 02:23:10PM -0700, Nick Desaulniers wrote: > On Fri, Oct 18, 2019 at 9:11 AM 'Sami Tolvanen' via Clang Built Linux > wrote: > > > > Only reserve x18 with CONFIG_SHADOW_CALL_STACK. Note that all external > > kernel modules must also have x18 reserved if the kernel uses SCS. > > Ah, ok. The tradeoff for maintainers to consider, either: > 1. one less GPR for ALL kernel code or > 2. remember not to use x18 in inline as lest you potentially break SCS This option only affects compiler-generated code, so I don't think that matters. I think it's fine to say that we should always avoid the use of x18 in hand-written assembly (with manual register allocation), while also allowing the compiler to use x18 if we're not using SCS. This can be folded into the earlier patch which always reserved x18. > This patch is 2 (the earlier patch was 1). Maybe we don't write > enough inline asm that this will be hard to remember, and we do have > CI in Android to watch for this (on mainline, not sure about -next). I think that we can trust the set of people who regularly review arm64 assembly to remember this. We could also document this somewhere -- we might need to document other constraints or conventions for assembly in preparation for livepatching and so on. If we wanted to, we could periodically grep for x18 to find any illicit usage. Thanks, Mark.