Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp4935076ybv; Tue, 11 Feb 2020 06:11:13 -0800 (PST) X-Google-Smtp-Source: APXvYqxqwEgdWiU3hP06yctTW6H9XpBymPT6KetfIchXf61Ro86WQwm6Bu6QMaEUBs/X3TbOCHsx X-Received: by 2002:a05:6830:1e72:: with SMTP id m18mr5058180otr.226.1581430273366; Tue, 11 Feb 2020 06:11:13 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1581430273; cv=none; d=google.com; s=arc-20160816; b=m/vbZRtxtO934bTI+MJd+gV71nsCyFAWwLMGqg21SD62xEsaCxknrXIIsVCWNv/NbW 3rtAp7oaNfYA6ciIEbn+fuIgUkntbCX/enmrBAdBwdvn0QG9qHMQSGCVWq7RuTmXASpp pmW1YZfofoaPO8pS78Q2X4V6nlQd87VDt/sb+LR1tw5zrPQfqn71rBIQm2O7vq2Qw1JC IX9ZzvrUmK6KzcvgBDHDiUBSsAj57pD42VxcP81m0ppEQkqKjTr8Vl63jZ1Jy9I2hZov ZVgGTufaVXsKGWHVcowZYy3xTGvP7576S+kLnkuXgJiQOCma6sVH/5L/XXL7DvL3GIsA CAhQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=eNeJBt7f1kZr2UhkEpVEZjIa2Qqzd4EANgay0ciSC2g=; b=BpwcdUyvV7LlLGSeOTb6sRtICQdpKKJFRdqAZLKpxpsUP+BUXjkiKtLdN2nwq8q17b T8zbQS+0F/XI8YSvJkMqTKJkkxzl0KRufLOzI7ZsQupyE0DSkWvBEDd9HY4uUvB8Ydsy 5ItHBq8bSMRO96v5yb1/6DWnf/FMqXys5Vim93fIhM9uA7eyVc5efFbYgOqgDqrudmOc yF224mdU6FfP3y3qutXIRzfNMGfKC8GE4cj3GXM5cooWG+TSuaC4K44EK6+B7/JmITQ7 1+xc42A1+gM/YFtIXpSm70N/tt8y+JDHFEOTMmGxND+syeATUWULWuEoSujw720VYiVP hDAg== 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 m16si2312297otj.7.2020.02.11.06.10.43; Tue, 11 Feb 2020 06:11:13 -0800 (PST) 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 S1729993AbgBKN5d (ORCPT + 99 others); Tue, 11 Feb 2020 08:57:33 -0500 Received: from foss.arm.com ([217.140.110.172]:46444 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729986AbgBKN5d (ORCPT ); Tue, 11 Feb 2020 08:57:33 -0500 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 8CB6431B; Tue, 11 Feb 2020 05:57:32 -0800 (PST) Received: from [10.1.196.105] (eglon.cambridge.arm.com [10.1.196.105]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 541BF3F68F; Tue, 11 Feb 2020 05:57:30 -0800 (PST) Subject: Re: [PATCH v7 11/11] arm64: scs: add shadow stacks for SDEI To: Sami Tolvanen Cc: Will Deacon , Catalin Marinas , Steven Rostedt , Masami Hiramatsu , Ard Biesheuvel , Mark Rutland , Dave Martin , Kees Cook , Laura Abbott , Marc Zyngier , Nick Desaulniers , Jann Horn , Miguel Ojeda , Masahiro Yamada , clang-built-linux@googlegroups.com, kernel-hardening@lists.openwall.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org References: <20191018161033.261971-1-samitolvanen@google.com> <20200128184934.77625-1-samitolvanen@google.com> <20200128184934.77625-12-samitolvanen@google.com> From: James Morse Message-ID: Date: Tue, 11 Feb 2020 13:57:29 +0000 User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <20200128184934.77625-12-samitolvanen@google.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Sami, On 28/01/2020 18:49, Sami Tolvanen wrote: > This change adds per-CPU shadow call stacks for the SDEI handler. > Similarly to how the kernel stacks are handled, we add separate shadow > stacks for normal and critical events. Reviewed-by: James Morse Tested-by: James Morse > diff --git a/arch/arm64/kernel/scs.c b/arch/arm64/kernel/scs.c > index eaadf5430baa..dddb7c56518b 100644 > --- a/arch/arm64/kernel/scs.c > +++ b/arch/arm64/kernel/scs.c > +static int scs_alloc_percpu(unsigned long * __percpu *ptr, int cpu) > +{ > + unsigned long *p; > + > + p = __vmalloc_node_range(PAGE_SIZE, SCS_SIZE, > + VMALLOC_START, VMALLOC_END, > + GFP_SCS, PAGE_KERNEL, > + 0, cpu_to_node(cpu), > + __builtin_return_address(0)); (What makes this arch specific? arm64 has its own calls like this for the regular vmap stacks because it plays tricks with the alignment. Here the alignment requirement comes from the core SCS code... Would another architecture implement these scs_alloc_percpu()/scs_free_percpu() differently?) Thanks, James