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 6AC82C28B30 for ; Thu, 20 Mar 2025 22:30:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8170B280002; Thu, 20 Mar 2025 18:30:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7D145280001; Thu, 20 Mar 2025 18:30:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 665D1280002; Thu, 20 Mar 2025 18:30:11 -0400 (EDT) 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 43803280001 for ; Thu, 20 Mar 2025 18:30:11 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 55571C118D for ; Thu, 20 Mar 2025 22:30:12 +0000 (UTC) X-FDA: 83243373864.18.FC93A49 Received: from mail-yb1-f172.google.com (mail-yb1-f172.google.com [209.85.219.172]) by imf07.hostedemail.com (Postfix) with ESMTP id 5700B40007 for ; Thu, 20 Mar 2025 22:30:10 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=rivosinc-com.20230601.gappssmtp.com header.s=20230601 header.b=YznMgeud; spf=pass (imf07.hostedemail.com: domain of debug@rivosinc.com designates 209.85.219.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=1742509810; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=JhKgSRxm2mNSCqvm5Zj9K3Ods9oUsUl94h74lzVe+vg=; b=IxOxpZaodWaj2UZEeQDZWVAETnbWwALHHjgR8lmbimuQEEGsM0WZFiwS5rqeikwtp1K+RE bZfpcQN6k7CLp4OwrKKieeLiIDIaI25CTFGJJIDYrKgO3xSICx230g44xz5PKfjUl3q0ZU mM+3h3OtmVuOtyGPPcdG4REvch29Fto= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1742509810; a=rsa-sha256; cv=none; b=s2ZYfq3sIb9pf38FS+riW0SiZ/0vgbAQehQIgOucJIRHYJQEjG+9+wRsw1b5av4BSJcjQw fpIx6xg8aOtYnw0RDSO3gusJjsYkgohphHU+4LOIzeDq6Sr1FdVqqNWW8yLZrZFI7ndKw6 ujl5qh1QZW/rfZsI8VRVYDhiBTuTlig= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=rivosinc-com.20230601.gappssmtp.com header.s=20230601 header.b=YznMgeud; spf=pass (imf07.hostedemail.com: domain of debug@rivosinc.com designates 209.85.219.172 as permitted sender) smtp.mailfrom=debug@rivosinc.com; dmarc=none Received: by mail-yb1-f172.google.com with SMTP id 3f1490d57ef6-e63a159525bso926384276.2 for ; Thu, 20 Mar 2025 15:30:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20230601.gappssmtp.com; s=20230601; t=1742509809; x=1743114609; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=JhKgSRxm2mNSCqvm5Zj9K3Ods9oUsUl94h74lzVe+vg=; b=YznMgeudCRNbJDQiPJAvlKZfDPRtWQyKtEpMGASyjaBCzC/xR9bZVWZNz6OdTyE1oN vHOmHV3UkTKRmErw8XrAuk1r6LA5Me45bAHRsa8qgcNpbwuDPGjYMATCZyHt2HNEft2U hJssF1tXcK6i5Lj2yjWPqx0ZQbHSVRNDanlpkix6xI3nZXChpFSI06e1cKlxE9fmfwe5 6gh715g6t1qsmV586u7lvTtYNOi24mOu4t+6DMrbCM0BiSUse7jY3K04n7S5qE8y8k8E b+T70M8HmZeyh9NYvQ4jdKXXkOKeJGvz1Zn0rh0LTfF9uad7rVzJXKthDFzIMzfty2CO 7oow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742509809; x=1743114609; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=JhKgSRxm2mNSCqvm5Zj9K3Ods9oUsUl94h74lzVe+vg=; b=fOWA5fQceaH1mLawYfRqiZSVaIy9nGZTx423jcnMvMSlIvK/JUp/IuozOkVSHzpo/k 78AfH+6JV63ElYy7wWVlez96GePZm/RxdDXwg9A0pQRJj4NVOI+5HQhO/gGlaHwKZs3r qD0Od7opI1SEcDAWVDkHACQNrG1w4pQEn2gn/+W3wp5YZ4gL7VE9JtXeAaWFZhKG46Cr +WGRkqVA+EBKogUTKJdpByr6oyHfyWmzElyd+SdUuZL4zwYbTyqWw8FJWF6QWe3QjllA /qeE2cPXejly58REhYpv61J/TCTfziSNrK/d4qJiWAPMhWXF20vbNxVDnhrARW90pyRp 4mfw== X-Forwarded-Encrypted: i=1; AJvYcCXjMF5q+tNhW6rgdUP4Cbg9/oityzZ1PuOjiQnT9/k2C4S6kHxYwLtYidLVO8Rg0HFSanCyRUls1Q==@kvack.org X-Gm-Message-State: AOJu0Yyx2EQ2s1zfuqClT4ptOyiyvmzjll9s0Zh7ljWLDLtd8/aaqHMb LiquWgpSkz2sE1IUPsme5qQLVtVTWLKJvsTz1QDS/jTU/b3858E2Ql3pQkSaKPXDY9Xb/GIXnPW BZuXaaFPzR1aAlVg6HqFRI44otKll0i3JhBsxyg== X-Gm-Gg: ASbGncskslhdqI2lOV6NWGoKcbtZ32QlUa2wknw2OAwvw4Hb/S1ZpANftVQ80a89HhU fSlBO49nGRACzI4Qd1+t9fQPQXTpRw+VnIfWKsjKh5b3oBNIlqN3tz7RN/G0y68SpcyECfiH5R+ 8K5r0G4LqX4tU5DaQi2cYq5Me2/24= X-Google-Smtp-Source: AGHT+IEQPzBHifdPzQrM8MhMztEZK/jnjn8OcNor9KhvI4hEsyHN6f7exl2vjGFEVUFZVWt5FCpCyI9kZub1gEwdZzk= X-Received: by 2002:a05:6902:a05:b0:e60:99d2:cbc2 with SMTP id 3f1490d57ef6-e66a4db6ba8mr1114497276.25.1742509809144; Thu, 20 Mar 2025 15:30:09 -0700 (PDT) MIME-Version: 1.0 References: <20250314-v5_user_cfi_series-v12-0-e51202b53138@rivosinc.com> <20250314-v5_user_cfi_series-v12-25-e51202b53138@rivosinc.com> In-Reply-To: From: Deepak Gupta Date: Thu, 20 Mar 2025 15:29:55 -0700 X-Gm-Features: AQ5f1JpPoZ6b9vZ5xwZpI2oxEH4zoWU0U5E6Pfiy0DThCuNWaEl3L1CWR9SNfKo Message-ID: Subject: Re: [PATCH v12 25/28] riscv: create a config for shadow stack and landing pad instr support To: =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= Cc: 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 , 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, Zong Li , linux-riscv Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 5700B40007 X-Stat-Signature: 5ms5gjsjtmik5owi14xof6z78puaeo7f X-HE-Tag: 1742509810-616420 X-HE-Meta: U2FsdGVkX19gZHZ7bE/DBAZxkML3wFivbi/KMPLIETE5n6/7LE+Sm4+LcZ2Hxqw+F1077cr6Tgz0pHGHWcBw/7McsgPI1VrPW+vAqtwCQTkTUWfYYImik5HyA+zhqIzr2+Ew00KEw0JfLMbPQpjdKwgAaXkE/yLiGt+52I0DAYQN1yYsc9UL9aZCSBqsIcjaQtD2StqK7w6IgFA26fsEbhEsJd5VTOjbEFZXWSYskmamgGVWU0Auy9+YBnhWF0wNgh4SZW+MD1evUHzGrYqkTrMXTBLyRslwGW9Pogbg9ChQqN23SnsuTxQNWBfk3HtkydZ1bmahiIRBBdC8kq7sVBDwbCSY15ceyKtv73nlwzb+af0htCvatnS8X7f2PqZQVIc5blRWEl21+ar0bvnfkr74mVSm0X7CHCqlZc4NbCFmcYk2qkIlqWTRpbh/EXUnFq+5JpA3AngHIk19gvITozSY7UH4FlrEjlnXKtPU8+NiKjYtD8y0fxyBosKRN0PMnROOW01/SKuA+RUneGxgEOsER6niuerRnPyX9xzwrba1+mbo8OqFiu34D2QqutRX1/U/idjn67z/hec4NKPAKyxvjUqz1jVEJsolWepBdmiljDS6Qgv6k6DX7ruBrz2SIsZ467bjWAqhWJ4xwdGDnIYd4RYvgXpKURSfsR+b0Ej80Q0WnBgpcBnmeUxM8PEiP3BQUzV/5BjDzky8H67j3PuGz0sKA/lVwdNjuirU7VBlvYaW4FLuXN5TEy9VBb7rflRoUn+Yo/LeoUp5QXnYhbMOIZZA65qxqq/q67pNPtmWaxPYM9E7GTesoiA69j/VuHEZysvJ06DnRqy/P2q44EvaXBuj3KtC8sIVB9Nf/u64kbGM8UKw0yAuZqlRpH5P3SYcLAIiB5AwTs6vr6DpQTsaCkSgpaMLotEux11czu/xPmfJa4KpvrWD7E2GJaVE/6w6dmRM8TXK8W9Rs7y iQE2gou8 TQyIwxbiOIe7ou3P7yjS1Poo/h5wFmiK5DgIPzKWE+R7THkAah0FEG77PL724IQJXoaeao4j+4glFQhqWUGP3JkeuTdUrjFXrcBJ4rHGihauPcSIIWYDUoUoVGKldXCWM7Z96UnC0AGjwuKqkomcvlV8Ng8FcQ31ZwvTpxUuVL+PTI9ankglOQ4STq2ZugQpt3yfGxy8Sbjwy0SYfq2TPKOqof6czhN0F5OcV6CSE/mRzmSqcopC4ZhFeStDURKNsFu9Zs9MPgV7jaZ07WvIi25oXMGj5u07EpB9D7uf3ObMCZqVxcmPA08CEkNLHovyy3RtO9AQwuExas7gy9/MShdQtU6bkeFGeLnN7OdpZYyivnorpxAOWrQlcZWLv1rjhIakRh9aYrRlClh6iA0KdXwM8Lc5o4Zu/3msnEMHvRm4ofBSbLuAkCwoSd8lhL/WIHyZdmBRsyAFHI/TjC+hmchHj2aFJeyhQEznt/OkMVukSza8= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, 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 Thu, Mar 20, 2025 at 2:25=E2=80=AFPM Radim Kr=C4=8Dm=C3=A1=C5=99 wrote: > > 2025-03-14T14:39:44-07:00, Deepak Gupta : > > This patch creates a config for shadow stack support and landing pad in= str > > support. Shadow stack support and landing instr support can be enabled = by > > selecting `CONFIG_RISCV_USER_CFI`. Selecting `CONFIG_RISCV_USER_CFI` wi= res > > up path to enumerate CPU support and if cpu support exists, kernel will > > support cpu assisted user mode cfi. > > > > If CONFIG_RISCV_USER_CFI is selected, select `ARCH_USES_HIGH_VMA_FLAGS`= , > > `ARCH_HAS_USER_SHADOW_STACK` and DYNAMIC_SIGFRAME for riscv. > > > > Reviewed-by: Zong Li > > Signed-off-by: Deepak Gupta > > --- > > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig > > @@ -250,6 +250,26 @@ config ARCH_HAS_BROKEN_DWARF5 > > +config RISCV_USER_CFI > > + def_bool y > > + bool "riscv userspace control flow integrity" > > + depends on 64BIT && $(cc-option,-mabi=3Dlp64 -march=3Drv64ima_zic= fiss) > > + depends on RISCV_ALTERNATIVE > > + select ARCH_HAS_USER_SHADOW_STACK > > + select ARCH_USES_HIGH_VMA_FLAGS > > + select DYNAMIC_SIGFRAME > > + help > > + Provides CPU assisted control flow integrity to userspace tasks= . > > + Control flow integrity is provided by implementing shadow stack= for > > + backward edge and indirect branch tracking for forward edge in = program. > > + Shadow stack protection is a hardware feature that detects func= tion > > + return address corruption. This helps mitigate ROP attacks. > > + Indirect branch tracking enforces that all indirect branches mu= st land > > + on a landing pad instruction else CPU will fault. This mitigate= s against > > + JOP / COP attacks. Applications must be enabled to use it, and = old user- > > + space does not get protection "for free". > > + default y > > A high level question to kick off my review: > > Why are landing pads and shadow stacks merged together? > > Apart from adding build flexibility, we could also split the patches > into two isolated series, because the features are independent. Strictly from CPU extensions point of view they are independent features. Although from a usability point of view they complement each other. A user wanting to enable support for control flow integrity wouldn't be enabling only landing pad and leaving return flow open for an attacker and vice-vers= a. That's why I defined a single CONFIG for CFI. >From organizing patches in the patch series, shadow stack and landing pad patches do not cross into each other and are different from each other except dt-bindings, hwprobe, csr definitions. I can separate them out as well if that's desired. Furthermore, I do not see an implementation only implementing zicfilp while not implementing zicfiss. There is a case of a nommu case where only zicfilp might be implemented and no zicfiss. However that's the case which is anyways riscv linux kernel is not actively being tested. IIRC, it was (nommu linux) considered to be phased out/not supported as well. We could have two different configs but I don't see what would serve apart from the ability to build support for landing pad and shadow stack differently. As I said from a usability point of view both features are complimenting to each other rather than standing out alone and providing full protection. A kernel is built with support for enabling both features or none. Sure use= r can use either of the prctl to enable either of the features in whatever combination they see fit.