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 77626C3601E for ; Thu, 10 Apr 2025 09:46:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A48D66B02E8; Thu, 10 Apr 2025 05:46:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9CE266B02E9; Thu, 10 Apr 2025 05:46:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 86FBE6B02EA; Thu, 10 Apr 2025 05:46:03 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 672826B02E8 for ; Thu, 10 Apr 2025 05:46:03 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 5E16F807DA for ; Thu, 10 Apr 2025 09:46:03 +0000 (UTC) X-FDA: 83317653006.07.41298FD Received: from mail-wm1-f45.google.com (mail-wm1-f45.google.com [209.85.128.45]) by imf20.hostedemail.com (Postfix) with ESMTP id 79C5F1C0002 for ; Thu, 10 Apr 2025 09:46:01 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=ventanamicro.com header.s=google header.b=EcHBOJcO; spf=pass (imf20.hostedemail.com: domain of rkrcmar@ventanamicro.com designates 209.85.128.45 as permitted sender) smtp.mailfrom=rkrcmar@ventanamicro.com; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1744278361; 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=T8i8GZtfdY75DsuPGV8mdkCHtexeE8J8QTGC238f61s=; b=Y64G26w9PV1Vf6zDIKOBY+GkPnnRD7Qrsc9/vxGKB+AyxX3cB6n9oq46LV0/jhXhvxzmJz 3Xu+5X3pGkvxQZ5Z76pAPwt/UsX7IW8qmTuJC24qCXbehTAFJlGTP2/zD6Urco1dPTkl6l wfKGhMpkTkrVUypITeUdw0njCSQ1kbA= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=ventanamicro.com header.s=google header.b=EcHBOJcO; spf=pass (imf20.hostedemail.com: domain of rkrcmar@ventanamicro.com designates 209.85.128.45 as permitted sender) smtp.mailfrom=rkrcmar@ventanamicro.com; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1744278361; a=rsa-sha256; cv=none; b=kWNLXKlhktysPc25jfVpR7W4Mzjr1RWj/W5samIe6Mf96912HcQIuZVvxmMXn8NG2SM/63 SB8KtSX72zVnMjYTTVDmm2k16eb4liNoLtdq/LFl9/FP4TqC1j+OzdnMlH6UOAi85xrIxz wlZjPwXduRoSmSAk+YKUhg5W+ZLblqE= Received: by mail-wm1-f45.google.com with SMTP id 5b1f17b1804b1-43d64e6c83eso630275e9.0 for ; Thu, 10 Apr 2025 02:46:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ventanamicro.com; s=google; t=1744278360; x=1744883160; 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=T8i8GZtfdY75DsuPGV8mdkCHtexeE8J8QTGC238f61s=; b=EcHBOJcOF/XGiuA9/r/5lS811ti7z6E1dCf4cfjmDBzGiPd3JgO7RtHnN/9k3mHbV4 7cCZDR6Q5Xi/q/L5pAUZoNqlcCSE8Cz9W/rjDgRe2pJnMIW/hq9DrzZdhoCRCHlkdmTb 3ezMCvVHar1X/W+YY4egyHMeQa1iUUpQmeI2nTvEhXJmAVAG3a4odFxkV/COC/+vzFXx 0q6YQrOmZHZZdv0b7LFaQeOn3IiCyyVnsk09WSBG9FT5wgUei56qiCghCOEAt+sIgFca hUZZhIOELJ0lN8qinC9fQk1O2AR8I40EKnjzvTyvZQHo7YH4QAiZbVWhVpOeqdL867pk Zuug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1744278360; x=1744883160; 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=T8i8GZtfdY75DsuPGV8mdkCHtexeE8J8QTGC238f61s=; b=GRT8yqnYZwuVseJrZ57TFOuY4rzczIwZ8ry/fDhIQ+CkdigePk5YML8doEPHUBnHY0 8FZJKpxpiqGKauTA5KeTx1FBIzTsuzaw6XzTwCyu7woU48COs2jilZjo2z8b+L4yYk92 FH9VURAI6nZ03o1npeDheO25i9/mo1lnePUKgE7BdwCVGkOC0lAqchKheYOwflyA1SWM HJVgquvPEvXHczv5Q0I55vi27Q3sdyOj+bKdi6eqpUXfJMA9CZpA9DeaJiF+obosghSs GWq/YX858RZv6Ei6jmJOu9RZbjg8+2oxPBSKD8KvIRHkJtTSVt4FUz+o6GCPhj/WGy85 XItw== X-Forwarded-Encrypted: i=1; AJvYcCXhmbQOJQylxkGeu2zxme/QSArlSYBpu7cuLEtnVSTOSMkBsK5ZXR0RO3ToGkIguFJTnSIAVIbpow==@kvack.org X-Gm-Message-State: AOJu0YyB2Z3J8eppLd4jFRDTv84kVSptAMGk6Mat8uFgMaHp7ACxySIV cCf38e1X6kPFuu4b4/quwztyxFmrZuPtIgEuas70WD2+SSimOTnMe8/MDjASmGI= X-Gm-Gg: ASbGncvnj2SBAEpxv+whfIKqvdr5DBY5cwEAm1qS02joGRuF/bjP84ZCIFXcwvOlelX ma3RIZ10AZtp2i5qZvSSu7G6BUXfkxml9wPBg4M1VAHgEDycHp7FqeyedOqz2SBBinV1cGwrrgQ Buz4BJILlb3mzVRBQNsiNIfYDHT9/1lgrFU+wJFHN62rLPfO6c6ol4q/oYXhHC0RhlLKE5nVyfT vpBccyCfgkjOyrIqXahJUyDYZaL1SSVP7zIs2yx0CJJbYD8FKjvKqYOsTDgQsGREAToyHk+mYUO aAGnrZNJhF6UIxORTiul8GTej9Q/kR9oNgQVFbQlJS02Yf30 X-Google-Smtp-Source: AGHT+IGtn4otBiHZ5rhpzGojxm7Tp3rcDjovrmZXPH6P8CvTrnSeGNCclbDgZlnTp+GpEEnuS4B3vQ== X-Received: by 2002:a05:6000:430d:b0:39c:1258:32d4 with SMTP id ffacd0b85a97d-39d87ce1a29mr1909263f8f.16.1744278359773; Thu, 10 Apr 2025 02:45:59 -0700 (PDT) Received: from localhost ([2a02:8308:a00c:e200:7d22:13bb:e539:15ee]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-39d893611dcsm4217671f8f.9.2025.04.10.02.45.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 10 Apr 2025 02:45:59 -0700 (PDT) Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Thu, 10 Apr 2025 11:45:58 +0200 Message-Id: Subject: Re: [PATCH v12 12/28] riscv: Implements arch agnostic shadow stack prctls Cc: , , , , , , , , , , , , , , , , , , , , , "linux-riscv" To: "Deepak Gupta" , "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" 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-12-e51202b53138@rivosinc.com> In-Reply-To: <20250314-v5_user_cfi_series-v12-12-e51202b53138@rivosinc.com> X-Rspamd-Queue-Id: 79C5F1C0002 X-Rspamd-Server: rspam05 X-Rspam-User: X-Stat-Signature: w9iwqijs1w8dpba95pqgb7jmpzeusncp X-HE-Tag: 1744278361-978013 X-HE-Meta: U2FsdGVkX1/JXU22OseowRBere2WfJ/VD+/1h1U5Zzkv1VfjSe0PBuWfX0nufk4C7xjjrDgEIuQdcJ+8DXjT2xJdW0GZwVrxOoUhP59/jfpwhcM+IbLf2FW61OSGlsv0M0VRzrBPeggie3sE/w/cr5JlwrDswujAzAhxdvv9QPyFbn4jCvHgN1F98Yf+UHJeRxEJJ7mgDy2O6zgi4JZXlGSZ+xU75u4ouKk6ZlyAelZd+ozpjuU/qA3k18wk1xsY2FhSk8elIKZHY2h6pHHbBB5vkygc/0soN8QIbJZB6go1KDyfHaBLaO8BIJcZI+/MBGj9uI32iZ0s09zoTkzEypviW0FuawIPnwc6a5Z48zzQpH28M3aeGv6xwO2r4UbHoSag/Ypy1RRu7LNbudHYtSx/nc0klAn9X7fPiVKlTOM1z6OHRei4KhL9XsSMQM64nCwQ8yjl934wvDyTctjmTfI5+8dWWzEhFOrk/ZuoFdMoKaSd+WUaKFyyAy6hQXUCdxo9AuuK5aqcGmDD8Uezg1I6wpJLZnxOEy5jYiKSmAu3cZo4LzFLhHp5mmMPHQv1PJKizc7GHNiB5Es+Fub+chaUNEELrgmZ9C1PcFtIA/ZZoGlynY2DAPA82c3zIGB68M7+busgTqMAz1Ew+zsesXZMyViN6JpTi0IDZzAYVlUACSKbdXhsSrCCULhfd6YtWlOED4qYBZbLlJ2RZQIiIK+c82NXXP5vBsmNyoLvn0NrH9QqPt6PC50zgUd+PwjqKTpm+B4lx7+cT+uk6RlG1oEPFBqP4k+KL21gdQ5sru+DM7xoCL++g83kAJji89OeJxYChcLaNOZFx5LhNuhNwjJO5p72fc3oGY5YlcVxWvnj1fA0AEEw3SOxKR1vrcmWN12UGBE8BG8+/iAz/9snJ6OaO4bhiWw7tJNmdJdJLDhkhJxK/3EXTE27RE6rYf7U1eHUy+3YfCMfhHU1knt COIlKSqY EGfZjxzoXyJnAo3Vikk7RviqjPQHJELCXv54Lqj8wVC4oKCDBdRduLZ5j4C56CUGI0soL3HcLcPrKTxX/TTJbBDGWOgnhlTz4OvVpYSFIzwDUY04q9lrA9Mc5JZ0G82WK9mFMMhRJ+iHUv7PC7/s09ez/TxTHPMnenJ30er/AFpKHxDZSOV8pyz4gAxsklbycXez+a8GsaqtDbwa4U1WSEDFoIdhcyB9IAOYA7KUjBFcvEox/1NtFfiQkspczMMGqff94T4AVfLW7VCeqHg2kPzQnRgN1HlfONNHxAL+QaXllfNnvdU9ddaVu7V9aR2BsC65fU+6JxJg5ipirHMANN4DP2ZbWWH1iG7ihjdche/HKjVJ2JMI7+Emlb4uWdXTZ39f8f2bnw6O+nGJIVZpxWO1WZARzEqF6ONmt/PNAdhRHTIw3LJxOiqHhQ7e6ZMdnVISGT53e2pLTwT9DDwaCPLK3F7vfbhYaocsnT6IBsk2ExBpMBqDN4eCj+yG6MTzIGouqv6emo+clXGgFzyl64yWtYxlNXFMYWKD93pexe84hkhoseWTF2w7Mpj7UTA/JaaBYAbBZDH5gPWWoijyzPgczQU0avGiPaUBFDJogiT1XYCMcyY+LYm/RAxzbnI748hF3HLSzzJdflUHAKeqY0XiTWg== 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-14T14:39:31-07:00, Deepak Gupta : > diff --git a/arch/riscv/include/asm/usercfi.h b/arch/riscv/include/asm/us= ercfi.h > @@ -14,7 +15,8 @@ struct kernel_clone_args; > struct cfi_status { > unsigned long ubcfi_en : 1; /* Enable for backward cfi. */ > - unsigned long rsvd : ((sizeof(unsigned long) * 8) - 1); > + unsigned long ubcfi_locked : 1; > + unsigned long rsvd : ((sizeof(unsigned long) * 8) - 2); The rsvd field shouldn't be necessary as the container for the bitfield is 'unsigned long' sized. Why don't we use bools here, though? It might produce a better binary and we're not hurting for struct size. > diff --git a/arch/riscv/kernel/usercfi.c b/arch/riscv/kernel/usercfi.c > @@ -24,6 +24,16 @@ bool is_shstk_enabled(struct task_struct *task) > +bool is_shstk_allocated(struct task_struct *task) > +{ > + return task->thread_info.user_cfi_state.shdw_stk_base ? true : false; I think that the following is clearer: return task->thread_info.user_cfi_state.shdw_stk_base (Similar for all other implicit conversion ternaries.) > @@ -42,6 +52,26 @@ void set_active_shstk(struct task_struct *task, unsign= ed long shstk_addr) > +void set_shstk_status(struct task_struct *task, bool enable) > +{ > + if (!cpu_supports_shadow_stack()) > + return; > + > + task->thread_info.user_cfi_state.ubcfi_en =3D enable ? 1 : 0; > + > + if (enable) > + task->thread.envcfg |=3D ENVCFG_SSE; > + else > + task->thread.envcfg &=3D ~ENVCFG_SSE; > + > + csr_write(CSR_ENVCFG, task->thread.envcfg); There is a new helper we could reuse for this: envcfg_update_bits(task, ENVCFG_SSE, enable ? ENVCFG_SSE : 0); > +} > @@ -262,3 +292,83 @@ void shstk_release(struct task_struct *tsk) > +int arch_set_shadow_stack_status(struct task_struct *t, unsigned long st= atus) > +{ > + /* Request is to enable shadow stack and shadow stack is not enabled al= ready */ > + if (enable_shstk && !is_shstk_enabled(t)) { > + /* shadow stack was allocated and enable request again > + * no need to support such usecase and return EINVAL. > + */ > + if (is_shstk_allocated(t)) > + return -EINVAL; > + > + size =3D calc_shstk_size(0); > + addr =3D allocate_shadow_stack(0, size, 0, false); Why don't we use the userspace-allocated stack? I'm completely missing the design idea here... Userspace has absolute over the shadow stack pointer CSR, so we don't need to do much in Linux: 1. interface to set up page tables with -W- PTE and 2. interface to control senvcfg.SSE. Userspace can do the rest. > +int arch_lock_shadow_stack_status(struct task_struct *task, > + unsigned long arg) > +{ > + /* If shtstk not supported or not enabled on task, nothing to lock here= */ > + if (!cpu_supports_shadow_stack() || > + !is_shstk_enabled(task) || arg !=3D 0) > + return -EINVAL; The task might want to prevent shadow stack from being enabled? Thanks.