Message ID | 20240125062739.1339782-11-debug@rivosinc.com (mailing list archive) |
---|---|
State | New |
Headers | show
Return-Path: <owner-linux-mm@kvack.org> 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 3FFDEC47258 for <linux-mm@archiver.kernel.org>; Thu, 25 Jan 2024 06:29:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B1A306B009A; Thu, 25 Jan 2024 01:29:31 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id AA32C6B009B; Thu, 25 Jan 2024 01:29:31 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8F6116B009C; Thu, 25 Jan 2024 01:29:31 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 7C0036B009A for <linux-mm@kvack.org>; Thu, 25 Jan 2024 01:29:31 -0500 (EST) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 5E35D160D17 for <linux-mm@kvack.org>; Thu, 25 Jan 2024 06:29:31 +0000 (UTC) X-FDA: 81716856942.23.87973A9 Received: from mail-pf1-f172.google.com (mail-pf1-f172.google.com [209.85.210.172]) by imf13.hostedemail.com (Postfix) with ESMTP id 8E7F020008 for <linux-mm@kvack.org>; Thu, 25 Jan 2024 06:29:29 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=rivosinc-com.20230601.gappssmtp.com header.s=20230601 header.b=VUlVBavM; spf=pass (imf13.hostedemail.com: domain of debug@rivosinc.com designates 209.85.210.172 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=1706164169; 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-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=9N8f26gdn2cRJikP5qLVCVRN7EIk5o+zwHdVnNZOBlE=; b=d9/16EK0c05bx2vncwhuUPzV0aOR5AvUrcC4O6wz7+tP5xrA5Ocs2gG3eQnt68jUNWxi5V CYD31Ra0aZ+yhAXJfgZmUerxXJaX1rGX5KKc09nnH3a3svYj3VsxjQQe8P2yFR7IigN5LK wYxrMGTpv3AUAvSN2MH34WeVe2pnmOE= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=rivosinc-com.20230601.gappssmtp.com header.s=20230601 header.b=VUlVBavM; spf=pass (imf13.hostedemail.com: domain of debug@rivosinc.com designates 209.85.210.172 as permitted sender) smtp.mailfrom=debug@rivosinc.com; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706164169; a=rsa-sha256; cv=none; b=ms6tMNHj30sDkOGFiBDgBsPG/MIiLOfR2KWJg3aS5Eku9BwvF54NjS5qVjHNY9VxuRMmej e/yxY5JRDsWSxyzycxsiv+GpuE5gnD83gkGpVfg9k3mhXkq85iE/fk3NNedL38qTpA/Hrg f9gmhb/Fwniaw1xnRWFedcYu469wn80= Received: by mail-pf1-f172.google.com with SMTP id d2e1a72fcca58-6db0fdd2b8fso3346560b3a.2 for <linux-mm@kvack.org>; Wed, 24 Jan 2024 22:29:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20230601.gappssmtp.com; s=20230601; t=1706164168; x=1706768968; darn=kvack.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=9N8f26gdn2cRJikP5qLVCVRN7EIk5o+zwHdVnNZOBlE=; b=VUlVBavM+9HVVc8wHCM1j3wgLokN5UtlODnDYlymg4wTqa8Dh726tKOmiflg5+R1IE Mb00x5x9Irs5ijeYUFeD0OdAcSOx5EYbGB2dxUo2/kqGgAm+C2l0fqyzUv/pJ5NLk64G P14AHw59qt+DlnBpAscQt+MA8ldvDnZhujxI6C+FqOwu813OjP5j413nYqoj7Cr7xeMp G+5hkWDqRn1DI2s+8Je8AMAt2JaCGx5nrBOEDDYrACo1ZWCec6aZ2Wg4lOLgzyjfQRZR /InnwGAA/MujnRefJLau07Q254qY4Ef2wanSnyPqRreRZVN/xS9Om6xHQVG/DgeqHoS1 w6qg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706164168; x=1706768968; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=9N8f26gdn2cRJikP5qLVCVRN7EIk5o+zwHdVnNZOBlE=; b=o9HJnRe75PJGRqJggV/0V7U6Tu0AM/g3VQg3abLYsttWF1TcEmJFPfTEbW7Qiujrvp Pl75NEUwpq8jjKGkKPZ2w61P0hgFML6ABBJmI3NnL5YoxeX3MhO821a+ojHgA/5fNM9R noxg0zUecdP7Srr9wZB9DqzY+yCG4fOydC2bgu8oqR9IKHiV8css1p08XSIO9tvQTA2b DHkHG5lD4j0S3lMPDJiJonQ4xxbU08fNJ5oiMhVEQRmZ/kUF/mhPsO1OMs7NVQPzvgc4 9geB/5pqJZ5bGrJ0cOC68ApfVblxXDfn5XMMaeeyPKUzVwEIlPMIJg/fjgTnLrQe4Q/I OVtg== X-Gm-Message-State: AOJu0Yxhn7/z2u9Nh5FyE4vJ1EygGgG/6qypcYaWGwyLQHK6z0Z69TkR Yoj2I4QIaHnZHXuihl9OA7blvk/Tg0ClJmc7TvQZYTXnFOLWNAjbnUPy6d1yNhc= X-Google-Smtp-Source: AGHT+IHrQQhht3UiJlyKEtEWAFFtcgqnTtiAl+0dT+6axrsGaLK/T90q0i7kfWmqNxjWPLmEJD8+XA== X-Received: by 2002:a05:6a00:3d04:b0:6dd:a004:c195 with SMTP id lo4-20020a056a003d0400b006dda004c195mr250813pfb.60.1706164168419; Wed, 24 Jan 2024 22:29:28 -0800 (PST) Received: from debug.ba.rivosinc.com ([64.71.180.162]) by smtp.gmail.com with ESMTPSA id t19-20020a056a00139300b006dd870b51b8sm3201139pfg.126.2024.01.24.22.29.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 Jan 2024 22:29:28 -0800 (PST) From: debug@rivosinc.com To: rick.p.edgecombe@intel.com, broonie@kernel.org, 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 Cc: 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, debug@rivosinc.com, 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: [RFC PATCH v1 10/28] riscv/mm : Introducing new protection flag "PROT_SHADOWSTACK" Date: Wed, 24 Jan 2024 22:21:35 -0800 Message-ID: <20240125062739.1339782-11-debug@rivosinc.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240125062739.1339782-1-debug@rivosinc.com> References: <20240125062739.1339782-1-debug@rivosinc.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 8E7F020008 X-Rspam-User: X-Stat-Signature: itzj73c46izihyde7ow8ac4outuzre9c X-Rspamd-Server: rspam01 X-HE-Tag: 1706164169-885911 X-HE-Meta: U2FsdGVkX1/RrLxci4QIXymBhze1UoNeOgae7PqqqlB4NlA53GM4SaZT3xuPhb7qeJVsAuFvsWO+ohLaCv6WM5d8JPBkaCcMqluPrnHjo9vlgLj8YbT896mgEZBZhS8ijD3V15VOsA/wC9xEw4QeFnqMQU5AvW15gEIEGnQChvFNxjzmpmmLigxpIxdCuZaqqbsq5gJIBZPynzKi9oCIDIXoOYIT8FfyohZCRzznxlAplOfpKWXPuAWeGVgSApHWITQGlXN1DxH24gVtLOXMmCsX0ToqxJYbTV42IlJaS2OX0y2fDp9XFCLP+jWKf2ju5lU9KfwKV5wFOZrdbZM8Z9MzQASTNIb87mX9Zh/siQsLtqPdj7rwHG/wkfxrnifMjJnjRD1Xc0n98j0EZ401xDkydfdegpIA+RFeiIGICpv51m1kYAPiBnms6nRHHA6UkiuJK2OvHNTBtsLEhqVrAUcd0O7uQKyYu5P2t0SupHpXx6OcuLOC6hR2JXg1cnaILReKZnDuQkvnIug/XnBkP00ObjR430i39vXIRO9nMhCqEsaQCDdTgXKM7cTX537WQ5KUUwSzeGW42lD/T/WY8D+qt6DeTEDBcpHqfF8uM3GzVGOleGFXnpJEusUXl4cxWdNTMy0TTczUUfHd1Ks/WdvqpuCHWCmJ7jT/aRs/fQbRS+E8sG7wdNTwNAPLgquBrw82x20pT0XQ1H/umAyF0AS8fMPp/vwd4yNGRn+NyHC+gQZg+CBGIGl5z11s+Wd19R3vT6RkHd3AMJXf3y1hA4OCzqpkHeItdb5EW0LbaOn3U2wRV5o/w7N40+yg6PNssT4V4Um9YGSOHgQjBLQg3e/5DxN2knYyZGSh5KVNkyV6+kTshobM1Xr/4+NcHkXMAmfIJW+j67M1e0t/ZEXTox3zV4UFMn2dYw0Syq5z5nckceQIDo+LX/MoPCzaRS3nJ6VZmwnAMPSKlZ02uWo YKfYmKoV 6Z3OjfIHTOwd5oTITI+HtsHTvR4o7qPAb4P9GTzpODJmFiLqg3k15gKAHXb6Y+wfPh5GqHpjdA8fxTFvPm5ijd213r8boESZry9Te2AAVUSqoxjuZtLiyV5h9VRpeOJmb9wL7PeaQz7bwZKgCfgw1eQTM+qQf725EseNTLR6+g3aLIlGRYPIsJg/bD9A+s7O3Q6W3P3qPL+MBAoJMZJOlYV52BcSAUJ4zgskzMPwUdrR5ZYadV4QdET8HYg99R18LlNvcVjMcZOGTjbToXJXviw3HGuM/r5FfrpwBewCiuCF65Ox72dWlEH5txnwN39wlIAzdGjpfUgVK9X8T/qUOPzo39VOpxidxYEUaN1riGAuYBlACooiVFJV+0+IN8lQQZ8BjhC5eKqIl+JXLu1VcOWuhfhVhGRjWZaDafw3eonJ2LqkVdzP+sObLSDJGc/ElfJy6TsqrQDkr1VRslSqpIG8BcojEA/3s+xkvd5szpzyJiGfYdKHSx6kBSSnk7XoWGpYD8HXHICrYNSgzZ9OwjQ0FcQ== 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: <linux-mm.kvack.org> List-Subscribe: <mailto:majordomo@kvack.org> List-Unsubscribe: <mailto:majordomo@kvack.org> |
Series |
riscv control-flow integrity for usermode
|
expand
|
diff --git a/arch/riscv/include/asm/mman.h b/arch/riscv/include/asm/mman.h new file mode 100644 index 000000000000..4902d837e93c --- /dev/null +++ b/arch/riscv/include/asm/mman.h @@ -0,0 +1,25 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +#ifndef __ASM_MMAN_H__ +#define __ASM_MMAN_H__ + +#include <linux/compiler.h> +#include <linux/types.h> +#include <uapi/asm/mman.h> + +/* + * Major architectures (x86, aarch64, riscv) have shadow stack now. x86 and + * arm64 choose to use VM_SHADOW_STACK (which actually is VM_HIGH_ARCH_5) vma + * flag, however that restrict it to 64bit implementation only. risc-v shadow + * stack encodings in page tables is PTE.R=0, PTE.W=1, PTE.D=1 which used to be + * reserved until now. risc-v is choosing to encode presence of only VM_WRITE in + * vma flags as shadow stack vma. However this means that existing users of mmap + * (and do_mmap) who were relying on passing only PROT_WRITE (or VM_WRITE from + * kernel driver) but still getting read and write mappings, should still work. + * x86 and arm64 followed the direction of a new system call `map_shadow_stack`. + * risc-v would like to converge on that so that shadow stacks flows are as much + * arch agnostic. Thus a conscious decision to define PROT_XXX definition for + * shadow stack here (and not exposed to uapi) + */ +#define PROT_SHADOWSTACK 0x40 + +#endif /* ! __ASM_MMAN_H__ */ diff --git a/mm/mmap.c b/mm/mmap.c index 1971bfffcc03..fab2acf21ce9 100644 --- a/mm/mmap.c +++ b/mm/mmap.c @@ -47,6 +47,7 @@ #include <linux/oom.h> #include <linux/sched/mm.h> #include <linux/ksm.h> +#include <linux/processor.h> #include <linux/uaccess.h> #include <asm/cacheflush.h>