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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id AF8FEC48BEB for ; Thu, 22 Feb 2024 00:47:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3B9AA6B0092; Wed, 21 Feb 2024 19:47:19 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 36A006B0093; Wed, 21 Feb 2024 19:47:19 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 20A8C6B0095; Wed, 21 Feb 2024 19:47:19 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 0E4506B0092 for ; Wed, 21 Feb 2024 19:47:19 -0500 (EST) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id D6FD4A0C70 for ; Thu, 22 Feb 2024 00:47:18 +0000 (UTC) X-FDA: 81817600956.13.7708AB4 Received: from mail-oi1-f173.google.com (mail-oi1-f173.google.com [209.85.167.173]) by imf21.hostedemail.com (Postfix) with ESMTP id 0B4CD1C0008 for ; Thu, 22 Feb 2024 00:47:16 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=rivosinc-com.20230601.gappssmtp.com header.s=20230601 header.b=TApn4nSJ; spf=pass (imf21.hostedemail.com: domain of debug@rivosinc.com designates 209.85.167.173 as permitted sender) smtp.mailfrom=debug@rivosinc.com; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1708562837; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=PxnB8hIBaJHKU9GMJod5TzavYw729HDn9dbYWz/K8DM=; b=lVrhf5HdahNn7BMZCeMoXwIXZgGK5oBAGGhl5jilRwxjUwkTXIDS6nwuLXP3iGhbI2Ecug NQeeV3KEZoUvqpyVT6QMNDX0j80HvYy8aylpFIwrNgIsXhzYLJkHRQuDv0DtUDAJt2auwS 1uSHli+8Mwpo912DFgg7yeWEvZOfHyw= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1708562837; a=rsa-sha256; cv=none; b=uV9fW0HjvLsyOyPOwzF7FfFpLSpghb2brXV1znu/ls4vhFDZOycZTodq4ooE+A4Fly+P8M c47AEs0PRInVA+xxLfEMc568SRX0k5S4wjW5EDOFq2ycNpGgtMkR6faD1dHkhITYfwU3Rz rS+sMWzKmU5EHiSq335GRhIUPAi7eEI= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=rivosinc-com.20230601.gappssmtp.com header.s=20230601 header.b=TApn4nSJ; spf=pass (imf21.hostedemail.com: domain of debug@rivosinc.com designates 209.85.167.173 as permitted sender) smtp.mailfrom=debug@rivosinc.com; dmarc=none Received: by mail-oi1-f173.google.com with SMTP id 5614622812f47-3c17ac08a38so30570b6e.1 for ; Wed, 21 Feb 2024 16:47:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20230601.gappssmtp.com; s=20230601; t=1708562836; x=1709167636; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=PxnB8hIBaJHKU9GMJod5TzavYw729HDn9dbYWz/K8DM=; b=TApn4nSJtEEMs6d/xNw6fL45C+Ww1QI7twhv/EFHy95LUgcaYOgjuxlKDViTyHIzPt QibHL7O3SpJGFvy4+4hU7IQWvIGRdpAnJe2KDXFyuF4Dbb0eICXZxW+DAUGnynxfk4OT UAU4oHsYk88lVH7Q76CbOlSE2wRtkWyOQLBbHR7Z7QrW71puDY0YPEcD67udqToPl8Gu sG4VEqzPEiQ9xZUqxUHCxSlnbXg675+YqYW8tQywnpb3ISZbJ+iaNH6cgEwIdUB1xcuS Nx/sF8usldOU4bnDJ8IoE7oyAEfsq3vX4YS7P7WdxwjHF00pP+Jc8h+jg6S07bijQmzf uTzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708562836; x=1709167636; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=PxnB8hIBaJHKU9GMJod5TzavYw729HDn9dbYWz/K8DM=; b=UHSTtqQ19H4Bn5vUJ3ttelVz8pFKiPRNmN5qwHBo8v8JaYRY+KjExl90ihxIq8kV7i ps/VHYkFW9oK2fvW8UAfkunjrH7ZWCzqcw6XpEmdbxgAFr0ccAV4L+iuLWJHhgzVDVgs XUibYe+u3lRdkBgyCicT7mUi3m3oq4iI/tkcaBgZEgD6f0lhe9MIOzcX/pmpwV7cjcaU VQH+9mfAG+/QN1eT4nqigykI590wyPgBjjR5si4olIOLBLXSq6SK+v/Wd+ZfhTEVuC1W ZYkKmdI8DZYWrlvb7RezuQCIxfktdRPO+IYeY7usfdKx5Le0c693y2tJRd9g/Ogyq1Er 39tw== X-Forwarded-Encrypted: i=1; AJvYcCWbRI2hd1vyUlrbaUAqxk4MTFeFhb2xGURz+WDd+VlCmk/ATw9/uYyuL5OuLTIme/ge3fB1kQLiB5dpPD+2azSFh1A= X-Gm-Message-State: AOJu0YzVGIdtagikn4+brt1GvQDNOgPrqUxt79rop55HA0VrsNkE5rph kblsYCteVoxAdkqJm5iOYh95tihKzuNMcEM1UlzR659ZcaBxdVXiGctRjk7dG5Q= X-Google-Smtp-Source: AGHT+IFSLTMc3hCuIYilhHI07UG+3jHSb+dOia9uI0EVHy8hIHGEMNdRSjhvd4xYo+3moab7FJoglQ== X-Received: by 2002:a05:6808:170f:b0:3c1:5440:d2c5 with SMTP id bc15-20020a056808170f00b003c15440d2c5mr11757138oib.38.1708562836074; Wed, 21 Feb 2024 16:47:16 -0800 (PST) Received: from debug.ba.rivosinc.com ([64.71.180.162]) by smtp.gmail.com with ESMTPSA id f10-20020a056a000b0a00b006dddf2ed8f0sm9533333pfu.154.2024.02.21.16.47.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 21 Feb 2024 16:47:15 -0800 (PST) Date: Wed, 21 Feb 2024 16:47:11 -0800 From: Deepak Gupta To: Mark Brown Cc: rick.p.edgecombe@intel.com, Szabolcs.Nagy@arm.com, kito.cheng@sifive.com, keescook@chromium.org, ajones@ventanamicro.com, paul.walmsley@sifive.com, palmer@dabbelt.com, conor.dooley@microchip.com, cleger@rivosinc.com, atishp@atishpatra.org, alex@ghiti.fr, bjorn@rivosinc.com, alexghiti@rivosinc.com, corbet@lwn.net, aou@eecs.berkeley.edu, oleg@redhat.com, akpm@linux-foundation.org, arnd@arndb.de, ebiederm@xmission.com, shuah@kernel.org, brauner@kernel.org, guoren@kernel.org, samitolvanen@google.com, evan@rivosinc.com, xiao.w.wang@intel.com, apatel@ventanamicro.com, mchitale@ventanamicro.com, waylingii@gmail.com, greentime.hu@sifive.com, heiko@sntech.de, jszhang@kernel.org, shikemeng@huaweicloud.com, david@redhat.com, charlie@rivosinc.com, panqinglin2020@iscas.ac.cn, willy@infradead.org, vincent.chen@sifive.com, andy.chiu@sifive.com, gerg@kernel.org, jeeheng.sia@starfivetech.com, mason.huo@starfivetech.com, ancientmodern4@gmail.com, mathis.salmen@matsal.de, cuiyunhui@bytedance.com, bhe@redhat.com, chenjiahao16@huawei.com, ruscur@russell.cc, bgray@linux.ibm.com, alx@kernel.org, baruch@tkos.co.il, zhangqing@loongson.cn, catalin.marinas@arm.com, revest@chromium.org, josh@joshtriplett.org, joey.gouly@arm.com, shr@devkernel.io, omosnace@redhat.com, ojeda@kernel.org, jhubbard@nvidia.com, linux-doc@vger.kernel.org, linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-arch@vger.kernel.org, linux-kselftest@vger.kernel.org Subject: Re: [RFC PATCH v1 15/28] riscv/mm: Implement map_shadow_stack() syscall Message-ID: References: <20240125062739.1339782-1-debug@rivosinc.com> <20240125062739.1339782-16-debug@rivosinc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 0B4CD1C0008 X-Rspam-User: X-Stat-Signature: 5oj1xrdzjfzerjsiguxm1nt1f1yoezuj X-Rspamd-Server: rspam03 X-HE-Tag: 1708562836-968947 X-HE-Meta: U2FsdGVkX1/RLvEmi1OGAxjFd/phLJiVC44k//EhuPbJKJfwfr/IEIWE6OjsgTRAOoxL4iilXxZoHe80w6+txOlYsjcZ08i9zGz4QQLVJEzgrjLgTnpJrWYETxuWii9ZwKGKuRNT15Aq8+jhuxHywMBxQ+nkyL477QW7FDPZNOBQUu6OLXPhKKSirm/UjZvVo6OhZZslNHUrkygcPfH3nooPuX1Ejlj8GvQgfT8NjoacpTxN5jDLGF6LvhxHm+zp6M/7xKdMy6Ypj+jkhhlWBxzVINTB2SsKodzis3gnA4FMx58cY3CTiwFZviu0J/mZ5TVYATHBCdRSEzFskkDNHSkLgQfCxjqWoGdFrCQNSgswxPYhQVBoTtdiRzIV8D5DHBAlzdEmBep4+zdg50chDzk7PRy/1AG6dLY48LkVTEUFf6YVk6SXr5jVQJ4wPqrcwFIOpvRNMoPdZDJveuPTHqNUEIQFUjAtFzejbreKrHJQBgmC/3sltqbgh85b/yOinQf2QF7wr6m6u3KSCy1B01GDT903THsFEnZZhu12MYDFOBBbA61MgLD6NFcSebJ+UxNH+eS4CsZ2G7nzNxW4uMrazA7CLCc4EPs3uXvBHa3Hy9Stf/8pZf/Y+uG587cGTgMpmhiWzpvdsTWbjvFjBxsQ3N3i4iNXW6vbgm19DtXEIWBDBaBVOh2q2YGvplCVUioagiDPWVTTabNGGmt2JqQTbj9j5oggYBPPst7DTi05aU/Y+uMEv2LU/aw5Strbz8q1OYhr0UfIjuwNga8jAO3kztHIGxhkEAr25QoSGdJcIUyxq2v/AlH+Vt6kAy+uUzJvW1zMlhEafR+JBxVEiIMq16ixsZ7cyJzSgBPTF7+2gFws8SeDuG293YWyyF+9p/zjv0/0SCVkQv6uLVjIts/mVJGEKHn3xz2MK0p6eHX9y0jPbvmpGCMJNCnTGDekCIF4qwp7ChHu+OD4/LD Wz5RFzRQ g8QXnvA9ls+7D/fJrBgnEkMc9VnhDUU2YzpBGdOv9Mf2UdVROmLBcgvDmx09fO2Lcl/E1yPIJT3ixsPtrO72JSLN59tPw+7LfNa/6/C6kAhSx3ik7ReJP1ZULFbYYIhnN6w8sArOmFsBjg4UPPU7MZzrWCtjjpvTbAFu4PtUl2q/+dpsJh6SAklZZ3D+v0m7VgjTzAz1/a2J8GqqKlRPXWTnSrsyUSR1LEjFks20xEB8QDeuhl5gKA4ujia8onwP/z39NSI0njr10q5HTz9HiRwrTjTuEuXIQ8ErM2fCrt+Fy3Z4CmmakmhcLblax+Nq9LQTUuGXJc0uwiGQpkuJTTTuymZdvUvxTO9QZYmIZW26or+R+2lm721LNp5nDTzrlXjob4zO7SvxPFg+dc6HAW/hTYbs1l4C+thyEEysBpBj6SoUkvhBDxtfq66PlHa97xr+CM+B7UGemqqflI+33kh70ugBg6/kGTJgPWs9NIUZaMt/K/tpeFvBpkXJyg+w+10VI X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Tue, Feb 06, 2024 at 04:01:28PM +0000, Mark Brown wrote: >On Wed, Jan 24, 2024 at 10:21:40PM -0800, debug@rivosinc.com wrote: > >> As discussed extensively in the changelog for the addition of this >> syscall on x86 ("x86/shstk: Introduce map_shadow_stack syscall") the >> existing mmap() and madvise() syscalls do not map entirely well onto the >> security requirements for guarded control stacks since they lead to >> windows where memory is allocated but not yet protected or stacks which >> are not properly and safely initialised. Instead a new syscall >> map_shadow_stack() has been defined which allocates and initialises a >> shadow stack page. > >While I agree that this is very well written you probably want to update >the references to guarded control stacks to whatever the RISC-V term is :P Noted. I'll do that in next patchset. > >> --- a/include/uapi/asm-generic/mman.h >> +++ b/include/uapi/asm-generic/mman.h >> @@ -19,4 +19,5 @@ >> #define MCL_FUTURE 2 /* lock all future mappings */ >> #define MCL_ONFAULT 4 /* lock all pages that are faulted in */ >> >> +#define SHADOW_STACK_SET_TOKEN (1ULL << 0) /* Set up a restore token in the shadow stack */ >> #endif /* __ASM_GENERIC_MMAN_H */ > >For arm64 I also added a SHADOW_STACK_SET_MARKER for adding a top of >stack marker, did you have any thoughts on that for RISC-V? I think x86 >were considering adding it too, it'd be good if we could get things >consistent. Please correct me on this. A token at the top which can't be consumed to restore but *just* purely as marker, right? It's a good design basic with not a lot of cost. I think risc-v should be able to converge on that.