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 45DAEC3DA6D for ; Fri, 23 May 2025 06:01:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A2F216B00C7; Fri, 23 May 2025 02:01:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9DF716B00C8; Fri, 23 May 2025 02:01:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8A7356B00C9; Fri, 23 May 2025 02:01:08 -0400 (EDT) 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 685796B00C7 for ; Fri, 23 May 2025 02:01:08 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 0B8945FBD8 for ; Fri, 23 May 2025 06:01:08 +0000 (UTC) X-FDA: 83473124616.19.C60F221 Received: from mail-pg1-f180.google.com (mail-pg1-f180.google.com [209.85.215.180]) by imf11.hostedemail.com (Postfix) with ESMTP id 1B0C840003 for ; Fri, 23 May 2025 06:01:05 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=rivosinc-com.20230601.gappssmtp.com header.s=20230601 header.b=rdzjPSdI; dmarc=none; spf=pass (imf11.hostedemail.com: domain of debug@rivosinc.com designates 209.85.215.180 as permitted sender) smtp.mailfrom=debug@rivosinc.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1747980066; 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=MM8qECzGuabOnUf85/QEm4aqRBTZg6DD4xWO9Ub0wak=; b=HfOW1D/YaisiJYsEgXcwuxSX6RwWzlvRZnD+97oYZ8356APKaRDUwcg8pXfk4wAStEqeKp AIzo02wzzBq5597RzZiOrjpa4NV+PoUumV1P9mc9UN23PCbbPuOixV452BzQDTi5PPaIRP 4WM8ZQ78CDxWEyv8Ed3C12Hhs3ulwrA= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1747980066; a=rsa-sha256; cv=none; b=S0q+vbG64dHjC49hx/iB6Jz+puT9RygkvRJi5W8vLDHYTpXZvSPHcFBJho/DR4YsrFOj7t 7mOLbTbtbFb2fBPtrhMCLK/NSnyS3b29baCxTrhWqDjJQ0uF3FoHOIJWHJBG9fTV9iStfj NMouYSbUjBMYDQ5T3JSIBLauJC5mq8s= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=rivosinc-com.20230601.gappssmtp.com header.s=20230601 header.b=rdzjPSdI; dmarc=none; spf=pass (imf11.hostedemail.com: domain of debug@rivosinc.com designates 209.85.215.180 as permitted sender) smtp.mailfrom=debug@rivosinc.com Received: by mail-pg1-f180.google.com with SMTP id 41be03b00d2f7-af59c920d32so5346934a12.0 for ; Thu, 22 May 2025 23:01:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20230601.gappssmtp.com; s=20230601; t=1747980065; x=1748584865; 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=MM8qECzGuabOnUf85/QEm4aqRBTZg6DD4xWO9Ub0wak=; b=rdzjPSdIUSbCoNFPJT1ZZ3Npl8MCSQ3X5ukht1EsSP9OoeaQfh5DovhtJmk3j0jwE5 Yp1KDcKboaGeYq/qEmo2UzSx7GIuNV26HiCvROUCJ0BIK34IqbzSa8MQco1dWEnHQHLQ 0qQFRxBRkJPk1fwcK/pinrJsrFUZdMv2T0HkukY7dQBRanNc64CmiKbavaCjCquEB+c+ kjTCETIvRFYn88ujdlX/x89nJ1dRfvkWNK0nNoK2r0Sg5z2uxiXevcNivC7BvmD1OIkv 7k7cmp7XWN0JCnN8Wr9IS+LHXx829jehvB1OoC7dorGf1DR+AmDlXGAfMQ2BgjOXZPuC +7dA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1747980065; x=1748584865; 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=MM8qECzGuabOnUf85/QEm4aqRBTZg6DD4xWO9Ub0wak=; b=XSpPZ5FMkDAnuh8mJ5jjrf2m7Q+2Y29EYFleTJHr9wxEb2vQ6QZLVefMoKV0I99SNZ ny2W4Pp3WHbmgHBzoY3QQ+rDsjQYAkvCihh5SkuCfJB200/RDsijWzUN1UTGxGbpRte1 3nIeW1O/8nkf071l4XvQEzt9Yl69pRwvVJD0gDwKUvSseVC1ACDng7nkyev9UJfEbJic OXW4uS7l0lWalI2YeUqgB37drIsfaf8d2DH8CQngbovmlwByfrpLl3/2S/0wwVAe5acv LA/FKOfMjJZlkKvg1SMOcsnNWnBmFSsLAjMeBVqio+/4G5xUI3fDOHPQpti9Qxj0iOU2 XdWg== X-Forwarded-Encrypted: i=1; AJvYcCXJUyZSkVhQIfgk0nnPmWRtwv23D1Uu6pctkOs+KsFriUWGPhNt+yeDgIOrK5r5bX0RvLkc/Tj0tw==@kvack.org X-Gm-Message-State: AOJu0YwN1O1dKFsgJONSYFEhfqW/9Emg7oVcWwatuASBRh7mazsVlFct eSZHMRlCI95LhStCmXB1gcqu8P3HmsQN7oSaC2WuyjfaHexri6JRru3d9SkJWWbUcuY= X-Gm-Gg: ASbGncvCy0jL2eiDltpTCx6UjhyZMpsBaWpx8sksP+ZbwiewI3hfgDW0T3bPuQZM1IC cRPI0GmpLwlwrTEmN4AHlpTpEFub17Lxy8Tw3Xl3QLsopEQxNO/q60mxfFDm4nriI8wlxvsACMO 4FvbyTPJwAHIp4vEaHAIz0Zg8+SMRUA9Pt/s+Ce0ycjfKoe1MAaapvfgwKJiVa1TzcWrukM0lqi 4O1PsO7f/to4JRMxVVwAA7mWuWRRpbbdLjrlgVWhOiRjYt79IpQKwo2kt2Huz5Ea2FOfMlDY4kw HbE1KkMwm3T7i1MtORMJc2fOdjzqxHlAtRQ75dkHLsuQGoP9jPJ7diQOCpMAVQ== X-Google-Smtp-Source: AGHT+IH2GKe/Xm4Ppo32AJJr6pQEKHz5ShbLWceyV6lc/d0LTWPehEZJe6GO4uOPRwS1AloDMoJLOw== X-Received: by 2002:a17:902:d4c1:b0:223:54aa:6d15 with SMTP id d9443c01a7336-233f21ccb31mr27879805ad.12.1747980064763; Thu, 22 May 2025 23:01:04 -0700 (PDT) Received: from debug.ba.rivosinc.com ([64.71.180.162]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-30f365f7a32sm6495296a91.49.2025.05.22.23.01.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 22 May 2025 23:01:04 -0700 (PDT) Date: Thu, 22 May 2025 23:01:00 -0700 From: Deepak Gupta To: Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Andrew Morton , "Liam R. Howlett" , Vlastimil Babka , Lorenzo Stoakes , Paul Walmsley , Palmer Dabbelt , Albert Ou , Conor Dooley , Rob Herring , Krzysztof Kozlowski , Arnd Bergmann , Christian Brauner , Peter Zijlstra , Oleg Nesterov , Eric Biederman , Kees Cook , Jonathan Corbet , Shuah Khan , Jann Horn , Conor Dooley , Miguel Ojeda , Alex Gaynor , Boqun Feng , Gary Guo , =?iso-8859-1?Q?Bj=F6rn?= Roy Baron , Benno Lossin , Andreas Hindborg , Alice Ryhl , Trevor Gross Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-riscv@lists.infradead.org, devicetree@vger.kernel.org, linux-arch@vger.kernel.org, linux-doc@vger.kernel.org, linux-kselftest@vger.kernel.org, alistair.francis@wdc.com, richard.henderson@linaro.org, jim.shu@sifive.com, andybnac@gmail.com, kito.cheng@sifive.com, charlie@rivosinc.com, atishp@rivosinc.com, evan@rivosinc.com, cleger@rivosinc.com, alexghiti@rivosinc.com, samitolvanen@google.com, broonie@kernel.org, rick.p.edgecombe@intel.com, rust-for-linux@vger.kernel.org, Zong Li Subject: Re: [PATCH v16 23/27] arch/riscv: compile vdso with landing pad Message-ID: References: <20250522-v5_user_cfi_series-v16-0-64f61a35eee7@rivosinc.com> <20250522-v5_user_cfi_series-v16-23-64f61a35eee7@rivosinc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20250522-v5_user_cfi_series-v16-23-64f61a35eee7@rivosinc.com> X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 1B0C840003 X-Stat-Signature: 9gzw3hxfqih4beoffpsc9xzwyrq7pf4z X-Rspam-User: X-HE-Tag: 1747980065-272408 X-HE-Meta: U2FsdGVkX1/Zp8syspWErYfefvxpuJTeqokO65vhioqUP2aplD/zvRmzP3ML0FW2nJcJjmMbLj4ezinEKaP6TXFbkL3wkSOC/F1i78sBSTnAhcaUd1MqBl3SSNzz6ZC5ybEs9oBMbzguSHrPQ9tsmifnHs8+YGRB3l6ldVyxj/Uvnsp4a8lXZNiN53BqyhVM8WtNUPCslmXCiT2kINbKt07MxLPflH8D0ZLmu4Wd9SdWtohQ7nnmsybKNFPUzkRQqqXTX1LcUGOp562MO2gq4R6c4ym+tpC2y1hgn/xPTa48SF4aUZkI/nb0rUWgdHuXDx3o/XT75wAd2QIXnRTVsDzGYxVgCT6v7yiZ8X2geErOF96UuCZKjg2BSLdkNYLYhwmTCfgXX+G0o4bFAwsbtjalVHmAPw4WQp0fYbQ+cKEj/5jpS1be7tlzJ+8QaRtzpanMk8Y8mqsMClnaTH/DTYoKiXFNwXNQ9npS06u8ICYt9vH8nL6pYJKlhXyRvmt5jx4Ldnx7nR/5XxdTNoK2InFUco/zXMouHR4R8T4lYJ3xiYCapOuruCE7I0kFSwhdtgsKH3pft1LfJTHyt3SSQiDHgeBjXidmk6y5gTQoIVF/QOvk1Wb+wrvNHDe0xtyKqIUQsThx+InXqJ/06+9SbxJqW4LHseRXp/Bh5sTK0jG9xlwXDhz6pqsqe49sBAkBbZjqEYVwA3o42ac25kl1RqMuP1GasrMH+Su2yeguhdn8D7kMDXLpNF1vgFAMLMfQkskjeSlH/8D83GiwOvs0GBeZzyAa+hkv8DfInlND8U0a7SVLnT0BpBmXm39cweRP2uY/q0kyEaoiTbSevwsWy2j3/gB0SiqOGW0KeDb8x+LcesUb8RnfoCgZv9pjUPi/9xqj3vV01jUaO0KcUWPDXF1H727Mw6/7kQMc+z9Li4yx/nhNKMQsc9uYogXmmT3xpOOLc7pVgm+KU78Hxo2 Nsp4heh/ ZscgJFOO+5liV37OIau8OcJDaW47z7rkWwBnrJrD5Dzsptr/bfCzTqFfi5Anewr/fxafcnOZOt5xueztovV/bOw6+to9OPogoDEtMjnvmIRFpzEHxMN8Q3xrqjZnzxTwxMclqODJl1v/aR7YYhNzqv330JAPQRYpugs/TU2PrKIE1IbNFZ84aZNxICBtbQeTLh9yNzDDUdH+DDhrVeFY6TWxuQgMAn5Y2hAHDWxu8i+8OBEEY0v+kWrG2DP9/gYEvdTKU6KCZUgqFwEDy1lAvPDAWeZRSKyG0+QqZ6CBFjsYJI36RVAj3CO9QA+09XwdEX8opJ28tayTVZztVBCvhevtlXvTUa6LYrP1/q42oQHuFmV5i7MXFpfNpZJS2SUQTxqHWNvvOM/NW4t5NXsHb7ypBSMe/KR6yM9O41IlZ53vBESnb55mstwo3EHzTqx8KLrLYtLCM9XA91iEx0nd2hqMpeMWncwtVevpjSL9rEJgfrPC6nx1ygPV8B5up+KtMTSvNbWf6teQqeA6UMObuyj961FCBfT5VNf2vvvgPV70DBPu7f8G6KwTNYA== 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 the topic of vDSO generation, I wanted to have a discussion thread. So I'll use this patch and create a discussion thread. Binaries in address space can call into vDSO and thus in order to have homogenous cfi policies, vDSO is also compiled with cfi extensions enabled. Thus it has shadow stack and landing pad instructions in it. Shadow stack instructions encodings are from zimop/zcmop encodings while landing pad is from HINT space of `auipc x0, imm`. Thus landing pad is truly backward compatible with existing and future hardware both. zimop/zcmop encodings are illegal instruction on existing hardware and any future hardware that will not implement zimop/zcmop encodings. RVA23 profile mandates zimop/zcmop encodings and thus any RVA23 compatible hardware should be compatible with libraries (including vDSOs) with zimop/zcmop instructions in them. Kernel which is built doesn't know upfront which hardware it is going to run on. It can be placed on top of a existing hardware, RVA23 compatible hardware or any future hardware which is not RVA23 compatible but has not implemented zimop/zcmop extensions. Question is should kernel be building two different vDSOs (one with cfi/shadow stack instructions compiled and another without cfi instructions inthem) and expose the one depending on underlying CPU supports zimop/zcmop or not. My initial hunch was to go with two different vDSOs in kernel and expose only one depending on whether zimop/zcmop is implemented by platform or not. However as ziciflp and zicfiss toolchain support is trickling into gnu- toolchain, shadow stack instructions are part of libgcc and all small object files that gets generated as part of toolchain creation (and eventually libc too). So eventually anyone running on a hardware without zimop/zcmop must be first building toolchain from scratch in order to build userspace rootfs and later packages. This sounds like a significant chunk of work and at that point they might as well just build kernel without `CONFIG_RISCV_USER_CFI` and should get vDSO without any cfi instructions in them. Thus I did not decide to provide multi-vDSO support in kernel considering it a futile exercise. I wanted to put my thought process here so that there is some discussion on this. On Thu, May 22, 2025 at 10:31:26PM -0700, Deepak Gupta wrote: >From: Jim Shu > >user mode tasks compiled with zicfilp may call indirectly into vdso (like >hwprobe indirect calls). Add landing pad compile support in vdso. vdso >with landing pad in it will be nop for tasks which have not enabled >landing pad. >This patch allows to run user mode tasks with cfi eanbled and do no harm. > >Future work can be done on this to do below > - labeled landing pad on vdso functions (whenever labeling support shows > up in gnu-toolchain) > - emit shadow stack instructions only in vdso compiled objects as part of > kernel compile. > >Signed-off-by: Jim Shu >Reviewed-by: Zong Li >Signed-off-by: Deepak Gupta >--- > arch/riscv/Makefile | 5 +++- > arch/riscv/include/asm/assembler.h | 44 +++++++++++++++++++++++++++++++++++ > arch/riscv/kernel/vdso/Makefile | 6 +++++ > arch/riscv/kernel/vdso/flush_icache.S | 4 ++++ > arch/riscv/kernel/vdso/getcpu.S | 4 ++++ > arch/riscv/kernel/vdso/rt_sigreturn.S | 4 ++++ > arch/riscv/kernel/vdso/sys_hwprobe.S | 4 ++++ > 7 files changed, 70 insertions(+), 1 deletion(-) > >diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile >index 539d2aef5cab..c2dd09bb9db3 100644 >--- a/arch/riscv/Makefile >+++ b/arch/riscv/Makefile >@@ -88,9 +88,12 @@ riscv-march-$(CONFIG_TOOLCHAIN_HAS_ZACAS) := $(riscv-march-y)_zacas > # Check if the toolchain supports Zabha > riscv-march-$(CONFIG_TOOLCHAIN_HAS_ZABHA) := $(riscv-march-y)_zabha > >+KBUILD_BASE_ISA = -march=$(shell echo $(riscv-march-y) | sed -E 's/(rv32ima|rv64ima)fd([^v_]*)v?/\1\2/') >+export KBUILD_BASE_ISA >+ > # Remove F,D,V from isa string for all. Keep extensions between "fd" and "v" by > # matching non-v and non-multi-letter extensions out with the filter ([^v_]*) >-KBUILD_CFLAGS += -march=$(shell echo $(riscv-march-y) | sed -E 's/(rv32ima|rv64ima)fd([^v_]*)v?/\1\2/') >+KBUILD_CFLAGS += $(KBUILD_BASE_ISA) > > KBUILD_AFLAGS += -march=$(riscv-march-y) > >diff --git a/arch/riscv/include/asm/assembler.h b/arch/riscv/include/asm/assembler.h >index 44b1457d3e95..a058ea5e9c58 100644 >--- a/arch/riscv/include/asm/assembler.h >+++ b/arch/riscv/include/asm/assembler.h >@@ -80,3 +80,47 @@ > .endm > > #endif /* __ASM_ASSEMBLER_H */ >+ >+#if defined(CONFIG_RISCV_USER_CFI) && (__riscv_xlen == 64) >+.macro vdso_lpad >+lpad 0 >+.endm >+#else >+.macro vdso_lpad >+.endm >+#endif >+ >+/* >+ * This macro emits a program property note section identifying >+ * architecture features which require special handling, mainly for >+ * use in assembly files included in the VDSO. >+ */ >+#define NT_GNU_PROPERTY_TYPE_0 5 >+#define GNU_PROPERTY_RISCV_FEATURE_1_AND 0xc0000000 >+ >+#define GNU_PROPERTY_RISCV_FEATURE_1_ZICFILP (1U << 0) >+#define GNU_PROPERTY_RISCV_FEATURE_1_ZICFISS (1U << 1) >+ >+#if defined(CONFIG_RISCV_USER_CFI) && (__riscv_xlen == 64) >+#define GNU_PROPERTY_RISCV_FEATURE_1_DEFAULT \ >+ (GNU_PROPERTY_RISCV_FEATURE_1_ZICFILP) >+#endif >+ >+#ifdef GNU_PROPERTY_RISCV_FEATURE_1_DEFAULT >+.macro emit_riscv_feature_1_and, feat = GNU_PROPERTY_RISCV_FEATURE_1_DEFAULT >+ .pushsection .note.gnu.property, "a" >+ .p2align 3 >+ .word 4 >+ .word 16 >+ .word NT_GNU_PROPERTY_TYPE_0 >+ .asciz "GNU" >+ .word GNU_PROPERTY_RISCV_FEATURE_1_AND >+ .word 4 >+ .word \feat >+ .word 0 >+ .popsection >+.endm >+#else >+.macro emit_riscv_feature_1_and, feat = 0 >+.endm >+#endif >diff --git a/arch/riscv/kernel/vdso/Makefile b/arch/riscv/kernel/vdso/Makefile >index ad73607abc28..441c5431d27e 100644 >--- a/arch/riscv/kernel/vdso/Makefile >+++ b/arch/riscv/kernel/vdso/Makefile >@@ -13,12 +13,18 @@ vdso-syms += flush_icache > vdso-syms += hwprobe > vdso-syms += sys_hwprobe > >+ifdef CONFIG_RISCV_USER_CFI >+LPAD_MARCH = _zicfilp_zicfiss -fcf-protection=full >+endif >+ > # Files to link into the vdso > obj-vdso = $(patsubst %, %.o, $(vdso-syms)) note.o > > ccflags-y := -fno-stack-protector > ccflags-y += -DDISABLE_BRANCH_PROFILING > ccflags-y += -fno-builtin >+ccflags-y += $(KBUILD_BASE_ISA)$(LPAD_MARCH) >+asflags-y += $(KBUILD_BASE_ISA)$(LPAD_MARCH) > > ifneq ($(c-gettimeofday-y),) > CFLAGS_vgettimeofday.o += -fPIC -include $(c-gettimeofday-y) >diff --git a/arch/riscv/kernel/vdso/flush_icache.S b/arch/riscv/kernel/vdso/flush_icache.S >index 8f884227e8bc..e4c56970905e 100644 >--- a/arch/riscv/kernel/vdso/flush_icache.S >+++ b/arch/riscv/kernel/vdso/flush_icache.S >@@ -5,11 +5,13 @@ > > #include > #include >+#include > > .text > /* int __vdso_flush_icache(void *start, void *end, unsigned long flags); */ > SYM_FUNC_START(__vdso_flush_icache) > .cfi_startproc >+ vdso_lpad > #ifdef CONFIG_SMP > li a7, __NR_riscv_flush_icache > ecall >@@ -20,3 +22,5 @@ SYM_FUNC_START(__vdso_flush_icache) > ret > .cfi_endproc > SYM_FUNC_END(__vdso_flush_icache) >+ >+emit_riscv_feature_1_and >diff --git a/arch/riscv/kernel/vdso/getcpu.S b/arch/riscv/kernel/vdso/getcpu.S >index 9c1bd531907f..5c1ecc4e1465 100644 >--- a/arch/riscv/kernel/vdso/getcpu.S >+++ b/arch/riscv/kernel/vdso/getcpu.S >@@ -5,14 +5,18 @@ > > #include > #include >+#include > > .text > /* int __vdso_getcpu(unsigned *cpu, unsigned *node, void *unused); */ > SYM_FUNC_START(__vdso_getcpu) > .cfi_startproc >+ vdso_lpad > /* For now, just do the syscall. */ > li a7, __NR_getcpu > ecall > ret > .cfi_endproc > SYM_FUNC_END(__vdso_getcpu) >+ >+emit_riscv_feature_1_and >diff --git a/arch/riscv/kernel/vdso/rt_sigreturn.S b/arch/riscv/kernel/vdso/rt_sigreturn.S >index 3dc022aa8931..e82987dc3739 100644 >--- a/arch/riscv/kernel/vdso/rt_sigreturn.S >+++ b/arch/riscv/kernel/vdso/rt_sigreturn.S >@@ -5,12 +5,16 @@ > > #include > #include >+#include > > .text > SYM_FUNC_START(__vdso_rt_sigreturn) > .cfi_startproc > .cfi_signal_frame >+ vdso_lpad > li a7, __NR_rt_sigreturn > ecall > .cfi_endproc > SYM_FUNC_END(__vdso_rt_sigreturn) >+ >+emit_riscv_feature_1_and >diff --git a/arch/riscv/kernel/vdso/sys_hwprobe.S b/arch/riscv/kernel/vdso/sys_hwprobe.S >index 77e57f830521..f1694451a60c 100644 >--- a/arch/riscv/kernel/vdso/sys_hwprobe.S >+++ b/arch/riscv/kernel/vdso/sys_hwprobe.S >@@ -3,13 +3,17 @@ > > #include > #include >+#include > > .text > SYM_FUNC_START(riscv_hwprobe) > .cfi_startproc >+ vdso_lpad > li a7, __NR_riscv_hwprobe > ecall > ret > > .cfi_endproc > SYM_FUNC_END(riscv_hwprobe) >+ >+emit_riscv_feature_1_and > >-- >2.43.0 >