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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 7F8A5C52D6F for ; Wed, 21 Aug 2024 15:38:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=n9+JbGoNDMnaaV8Ekm54wdMmtAy2mLY9DWwJHqg9IeE=; b=fmnkcDsTuDk+ERHrf6+mLYeUTT 0rCFx6nh8POm4AP3NPolb51y7CbvwVZYYDXh7DspX7K9BWHYoP7f8GQ0kdY4SXKkTSgB28S+1k29D OT3mebyaHTMD7eQXuxiEiH0wa+f/0IH9R0R7l3LV/kis3xLS/E3x+2wNoOKWGpXBc7wH/6Veuause plRWaolKMrQI7elDVNebgUydHheV+EH/vDs/jw25T1Qo0BIL3LjEgqApNDqw+jC0Y6DsURl7ciYj0 NZV1fOiTuOSLzdmgsh3a1+1L21JcmCPQcqV9fZFncX2B4XhxGDN2MowyucwdxDQI+7+g8h0FNmCby nWRC1e9g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sgnPJ-00000009WZW-3GkF; Wed, 21 Aug 2024 15:37:57 +0000 Received: from sin.source.kernel.org ([2604:1380:40e1:4800::1]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sgnOY-00000009WKH-2uuS; Wed, 21 Aug 2024 15:37:12 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id ED86DCE0E69; Wed, 21 Aug 2024 15:37:07 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BBEF4C4AF09; Wed, 21 Aug 2024 15:37:01 +0000 (UTC) Date: Wed, 21 Aug 2024 16:36:59 +0100 From: Catalin Marinas To: Mark Brown Cc: Will Deacon , Jonathan Corbet , Andrew Morton , Marc Zyngier , Oliver Upton , James Morse , Suzuki K Poulose , Arnd Bergmann , Oleg Nesterov , Eric Biederman , Shuah Khan , "Rick P. Edgecombe" , Deepak Gupta , Ard Biesheuvel , Szabolcs Nagy , Kees Cook , "H.J. Lu" , Paul Walmsley , Palmer Dabbelt , Albert Ou , Florian Weimer , Christian Brauner , Thiago Jung Bauermann , Ross Burton , linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org, kvmarm@lists.linux.dev, linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org, linux-mm@kvack.org, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org Subject: Re: [PATCH v10 22/40] arm64/mm: Implement map_shadow_stack() Message-ID: References: <20240801-arm64-gcs-v10-0-699e2bd2190b@kernel.org> <20240801-arm64-gcs-v10-22-699e2bd2190b@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240801-arm64-gcs-v10-22-699e2bd2190b@kernel.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240821_083711_175809_0B2F6A3F X-CRM114-Status: GOOD ( 22.99 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Aug 01, 2024 at 01:06:49PM +0100, Mark Brown wrote: > +SYSCALL_DEFINE3(map_shadow_stack, unsigned long, addr, unsigned long, size, unsigned int, flags) > +{ > + unsigned long alloc_size; > + unsigned long __user *cap_ptr; > + unsigned long cap_val; > + int ret = 0; > + int cap_offset; > + > + if (!system_supports_gcs()) > + return -EOPNOTSUPP; > + > + if (flags & ~(SHADOW_STACK_SET_TOKEN | SHADOW_STACK_SET_MARKER)) > + return -EINVAL; > + > + if (addr && (addr % PAGE_SIZE)) > + return -EINVAL; > + > + if (size == 8 || size % 8) > + return -EINVAL; Nitpicks: use PAGE_ALIGNED and IS_ALIGNED(size, 8). > + > + /* > + * An overflow would result in attempting to write the restore token > + * to the wrong location. Not catastrophic, but just return the right > + * error code and block it. > + */ > + alloc_size = PAGE_ALIGN(size); > + if (alloc_size < size) > + return -EOVERFLOW; > + > + addr = alloc_gcs(addr, alloc_size); > + if (IS_ERR_VALUE(addr)) > + return addr; > + > + /* > + * Put a cap token at the end of the allocated region so it > + * can be switched to. > + */ > + if (flags & SHADOW_STACK_SET_TOKEN) { > + /* Leave an extra empty frame as a top of stack marker? */ > + if (flags & SHADOW_STACK_SET_MARKER) > + cap_offset = 2; > + else > + cap_offset = 1; > + > + cap_ptr = (unsigned long __user *)(addr + size - > + (cap_offset * sizeof(unsigned long))); > + cap_val = GCS_CAP(cap_ptr); > + > + put_user_gcs(cap_val, cap_ptr, &ret); > + if (ret != 0) { > + vm_munmap(addr, size); > + return -EFAULT; > + } > + > + /* Ensure the new cap is viaible for GCS */ > + gcsb_dsync(); s/viaible/visible/ On the comment itself, the barrier does not ensure visibility in absolute term, it's all about ordering relative to other accesses. It might be good to clarify what we actually need in terms of ordering. One aspect came up in an earlier patch was around thread creation. For the current CPU, subsequent GCS accesses in program order will see this token. Classic LDR/STR won't without the barrier. I think this matters when we check the token in the clone3() implementation. Maybe write something along the lines of "ensure the new cap is ordered before standard memory accesses to the same location". Anyway, the patch looks fine. Reviewed-by: Catalin Marinas