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 A8A55C35FF3 for ; Fri, 21 Mar 2025 07:51:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3B342280002; Fri, 21 Mar 2025 03:51:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 33EB0280001; Fri, 21 Mar 2025 03:51:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1DE54280002; Fri, 21 Mar 2025 03:51: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 F1288280001 for ; Fri, 21 Mar 2025 03:51:07 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 8B58EC1DFA for ; Fri, 21 Mar 2025 07:51:08 +0000 (UTC) X-FDA: 83244787416.23.DF92813 Received: from mail-wr1-f47.google.com (mail-wr1-f47.google.com [209.85.221.47]) by imf10.hostedemail.com (Postfix) with ESMTP id 8E993C000A for ; Fri, 21 Mar 2025 07:51:06 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=ventanamicro.com header.s=google header.b=Q4yxRCrD; dmarc=none; spf=pass (imf10.hostedemail.com: domain of rkrcmar@ventanamicro.com designates 209.85.221.47 as permitted sender) smtp.mailfrom=rkrcmar@ventanamicro.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1742543466; a=rsa-sha256; cv=none; b=dRXrXY1OIu29H2+NQecbkywOocL0KINHKWam+r5WEgq2WsTlU3ETVoomReC09EuMWg4H3I OVF8YJor8m5FfPOQ5K1PJ04YNFvPFivikPYyNDaEV3kDygMvMEEZcBCJ9TY09L5J3aDiFo MEO/MIY/DYrYd1FMbqFp19lLI4/JWEQ= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=ventanamicro.com header.s=google header.b=Q4yxRCrD; dmarc=none; spf=pass (imf10.hostedemail.com: domain of rkrcmar@ventanamicro.com designates 209.85.221.47 as permitted sender) smtp.mailfrom=rkrcmar@ventanamicro.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1742543466; 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=PhIkdGys04hj0FOCl78FUSdH2+gL7DQzkmTGKMi3P1w=; b=k5Cb+RWl6fTvrI8IwX1xw2WDmIGxr+l1YoVnZAH044HDWbxwJAr0xATu6vLkDnwoJfBAMC /r+NLHWSsfaKEjBLIuNtM0WFLGN4HxQc0CmuR8YsbdH26ocTlSAbNcxF97rPNpq2e577rX VMlZlYxb9+1mQEkhPBra2R91kaPnmc4= Received: by mail-wr1-f47.google.com with SMTP id ffacd0b85a97d-39127effa72so194394f8f.2 for ; Fri, 21 Mar 2025 00:51:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ventanamicro.com; s=google; t=1742543465; x=1743148265; darn=kvack.org; h=in-reply-to:references:from:to:cc:subject:message-id:date :content-transfer-encoding:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=PhIkdGys04hj0FOCl78FUSdH2+gL7DQzkmTGKMi3P1w=; b=Q4yxRCrDjq8rOspTy2YaYRMUQ87oCAgesOIu5RgKn5TdCNuemm7UNSXeBETZrYgw9/ TVlLMDro4mKgJZUtlp0i0Mcwke3Pop+FB/04BGfSHOWL4SxR2cmmW7rOhRpJrqx/pP4I ONoswwUqo9K9A9lVYDBBuxJLJcDBMXo4C7Tixen2qxIyz4JOSAHV8drz08OyI/FQS/oF ySuTYjzeqLIvbvJ1HhlqyKRdkfbBWWODZ3faXgAkcZtzSjDIYC1x3HraJBzdb8rGR7BH hN7fq0EJqM2RxmGL8vHKloY0Q5Zcds5FqXbjd5M8lnzureGlr8qMRqvLqyDS5c3r1YGX 7OoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742543465; x=1743148265; h=in-reply-to:references:from:to:cc:subject:message-id:date :content-transfer-encoding:mime-version:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=PhIkdGys04hj0FOCl78FUSdH2+gL7DQzkmTGKMi3P1w=; b=pMn+Ti2Qo/6GJxN0yacG3/vG1omGk8VlmBmiKMS3T9LVx5In0eWxOYpZRoAcxkFIv5 9z8fhcwChyRD6GOb9X2sgzDcY2yn4MoIhs7X378CGAvVspRbuZyA6UEWiU02kyvPTczy H+SIYNeSxtL7i1rWs79cN4lti3aRIYWTa2s6sJS3lULYc1jP9DFXMvCxTADfZZ47siyC mSSQqb/sqBzR1CwPV9gRMYo3r3xyreIiQ7FbyXWH8UZUiwxK0iS6vWyddZBEzW9xV9kH jqaJXlQ36UivonQ93hNKHIS8ml0WaX/fBdRcqXMuDJEoRIt+LEgxSLSp4RQZPDipaFat 1ciw== X-Forwarded-Encrypted: i=1; AJvYcCWyJ6Wsz4IbBAweOUePzFUoc1y3zeCpsP/MEhfB6tEjk2pAGqrYVSUYLhGhLGlXTpNKb53HMkrfrQ==@kvack.org X-Gm-Message-State: AOJu0YyLJWVqkWpbCUQ8RYFojr9T8fO5Xvwy+BNasOrihnbQ1WS1An5q RKfcurqxoV1G/s+QnLaa2q6HpWdAiZQPYO1oxpD8OEb45s0WTOUC6xGPxQnY41Q= X-Gm-Gg: ASbGncseb9Pv/j0kdV/yksn0NphtC2DGnSSLTxRI3L6rtOfvkKYppsq3Q433SNI67Am x04FGvZdnNGVpMwDUnWG2ih3OTr32B6N5oc1mqL4fzmT8cjnUQHoZxqxgaX6YEuQNycyF5MLIsY NSXqkRM0d7b8yjq7lrCasx2LXj/n0a15q6rI4JkrwXc5ANF0EjBCTZ1nBlXVzX3Ko7ke40x/lB4 N9XmlqkXlDycqpmD8zh9KVt/RcUo1wxmazGUb6ycq8pxdxCm8EML5kU0HzmY0eTwStuGtcqwger 9EePgLz37IVImMFtiSEmIKT9L9XQy8puIIKRfjopHmyamnE8BzFBYYCNTZM7e+8iAMm2s8lp6VA CVJGx X-Google-Smtp-Source: AGHT+IGwi45hePFM2TZdMOTyXUgfdngf4+B913tg/H8YfeoX7CrwBIY2Kj9KlDmHfMfV0eRC+zYKag== X-Received: by 2002:a5d:598b:0:b0:38d:d743:7d36 with SMTP id ffacd0b85a97d-3997f93046emr899094f8f.10.1742543464931; Fri, 21 Mar 2025 00:51:04 -0700 (PDT) Received: from localhost (ip-89-103-73-235.bb.vodafone.cz. [89.103.73.235]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-43d4fdb06b9sm18758395e9.36.2025.03.21.00.51.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 21 Mar 2025 00:51:04 -0700 (PDT) Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Fri, 21 Mar 2025 08:51:04 +0100 Message-Id: Subject: Re: [PATCH v12 25/28] riscv: create a config for shadow stack and landing pad instr support Cc: "Thomas Gleixner" , "Ingo Molnar" , "Borislav Petkov" , "Dave Hansen" , , "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" , , , , , , , , , , , , , , , , , , , , , , "Zong Li" , "linux-riscv" To: "Deepak Gupta" From: =?utf-8?q?Radim_Kr=C4=8Dm=C3=A1=C5=99?= References: <20250314-v5_user_cfi_series-v12-0-e51202b53138@rivosinc.com> <20250314-v5_user_cfi_series-v12-25-e51202b53138@rivosinc.com> In-Reply-To: X-Rspamd-Queue-Id: 8E993C000A X-Stat-Signature: p7j8iefr199tfojhsa68qcwh1xi7qndt X-Rspam-User: X-Rspamd-Server: rspam06 X-HE-Tag: 1742543466-498988 X-HE-Meta: U2FsdGVkX1/ucktARFVoBhUkpy7KiqEWxFXetH9W1AMpTYAJa8VEu3Nye0LM9JZfDkhFxS5UXjmW/BT4irUyOTQaP8bJVW6Lt31DqXGJdtRCS2ewMCyiDwiWwYUxOE9dCom67oN7FETZLX/TgPwfnXeSFOy8Jcl60fIM0IAPhEq+9ZDB2ohV6b8VpJYt3ezQbvIz0IZiN6fYA4ATvl6jlpqNC7hIoW6ZGjimCHJvcqx6+JAdSBd8l/n9jKng0EFH3ilNIB2XxhkD5v6HY1fK+lX4YeEi18HDuEjl3yOoPVIv1xRTBQNy1zueuhte/p0wAyuVEys9USzmOdYEF+M9L0aah9tvVRoqLcx9Bqeo/xU//7WjqJMaXXktKoec8PebRXsrNGcgC7Noo6NKmysaJbjKWwNfZ8CeAEL4/PoHElTxNXG02fPkNPD/eeckOdkCSLQ43zsUyerlHy6h78jbCiPssc7WZihSh9MY3pfG0wUuF44QNnAt0U4RyIThXiiIRJY/g9FXg3UMML72AsYd58R6lOwX6Q116utmmiY/at+FZrzeOg3ph4d7CH8Z/jK/CEos5dDrdxQl74QzPuwX/yjsR1SIAcxqIT1mUQTvnlnTT1FpP6W3wwHTfoe2ho7nbKRmjQzu4x36uTtYRU/BnMfKMp0zoiyc7vXY8zGRNaHGE5w0ZcuPDE6UjUnqhX44gK7N4ReWKICviC1oP7CCSSFU9E8cGgFEVHKlLzP9kVN3/g5imAg7/F5zVsu4Dc5JC9PPoVRvsAn46zLY++Z9luqIsY5qnAMpkORuxXLG7e+CMEvw4Y3LjVkXqy9Kb2cQXy6eqyFaRYlf6B3WHqiOvYCyhC2Xk08dImgIKxSRVyjXfPo5H+YE8QPO3CwtVDVSYOFhFF5kYBhCA9PW7BKAK1Y9APM6NPVpSE1I4We83i1J6yd5KbQxbSl+lGA+YbCJZ5sNnTamhpzsj3IQGnR G2mGMWYM 9AP9JJ2wEm0LJu8b/+rL6LZVzO8oi7Kft0ukaUvSkQJ2u6bqfwELAaWGnbBinUFqim74H9GODTdy7GcMsGuJ8bcC9YmFf3U97k5DA/iodCA5f+E9459aWiYuJj3UflDIKSV0HMtwkdXBmgF2GV2u914EhSWbQ0cAHDd/pM6PBoUTdqewRqAP3OwrH2fmiUyg+pmENXLIP4bAyoHWOiUt0ES4erEeU+hIynKeX5arxWL8HaMsAduzH/u39BeAelXa4vrbMCYcYkfvSv8HLRpoRI9JGKdYVqqy+DeGM1E0/+GngALU2n+Sah2fVRP+CRF6kdYn58SZPt0orRN4I7W15BLRncn+1YA/0WCBHtpl2pRA+w6QYPsSpZTVeV/9YbSC9RvHg1QijLKiCMPlWPt0MWqzu7FnD/7ReTvlsQPl0UaBtm8WXf41y9DQCcs/jA2clvco1B7SXElaISzvoFEEj5ICZ67ik85dYOI01Xrrcl4DhvuIHcDB3wcVhLt8/njSp0OiqHVTSsA0BoXb/pxCfly8xy4gPgwsSKfaM5fABBiZrPGH6IRCYgMmE7WaSeP/CfRHc7iDRH5jbwZkX9J46cfMsP/QyaxIWKDqtROiPPAjs3BQozuSQ81PEgdDaZi1zJKf+Or4Lpl9+0OJPfvmRE4i0Cm7D6spbdybbpuysfeMlOjuDBr2GUVd0Ofcichm9ANuei86kXZdGJbkYhaYG250gzp0CW1n/etKu 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: 2025-03-20T15:29:55-07:00, Deepak Gupta : > 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 i= nstr >> > support. Shadow stack support and landing instr support can be enabled= by >> > selecting `CONFIG_RISCV_USER_CFI`. Selecting `CONFIG_RISCV_USER_CFI` w= ires >> > up path to enumerate CPU support and if cpu support exists, kernel wil= l >> > 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_zi= cfiss) >> > + 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 task= s. >> > + Control flow integrity is provided by implementing shadow stac= k for >> > + backward edge and indirect branch tracking for forward edge in= program. >> > + Shadow stack protection is a hardware feature that detects fun= ction >> > + return address corruption. This helps mitigate ROP attacks. >> > + Indirect branch tracking enforces that all indirect branches m= ust land >> > + on a landing pad instruction else CPU will fault. This mitigat= es 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 use= r > 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-ve= rsa. > 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. It would be my preference, but it's the maintainer's call. I think that landing pads could be merged earlier if they were posted separately, but this series is already on v12, so I don't want to force anything. > 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 protectio= n. > > A kernel is built with support for enabling both features or none. Sure u= ser > can use either of the prctl to enable either of the features in whatever > combination they see fit. Yeah, it will be rare, but if for some reason one feature cannot be used, then having just one is better than none. We can easily add compile options later and if we start with separate kernel parameters, then the users won't even notice a difference.