From: Deepak Gupta <debug@rivosinc.com>
To: Palmer Dabbelt <palmer@dabbelt.com>
Cc: Paul Walmsley <paul.walmsley@sifive.com>,
aou@eecs.berkeley.edu, apatel@ventanamicro.com,
ajones@ventanamicro.com, guoren@kernel.org,
mchitale@ventanamicro.com, waylingii@gmail.com,
greentime.hu@sifive.com, samitolvanen@google.com,
Bjorn Topel <bjorn@rivosinc.com>,
Conor Dooley <conor.dooley@microchip.com>,
jeeheng.sia@starfivetech.com, Heiko Stuebner <heiko@sntech.de>,
Evan Green <evan@rivosinc.com>,
jszhang@kernel.org, cleger@rivosinc.com,
linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1 2/2] riscv: envcfg save and restore on trap entry/exit
Date: Tue, 12 Dec 2023 17:02:43 -0800 [thread overview]
Message-ID: <ZXkCs9ypok5X/Wx2@debug.ba.rivosinc.com> (raw)
In-Reply-To: <mhng-ae72b5fd-358d-48e2-87cf-f571b67afe9e@palmer-ri-x1c9a>
On Tue, Dec 12, 2023 at 04:53:48PM -0800, Palmer Dabbelt wrote:
>On Tue, 12 Dec 2023 15:49:25 PST (-0800), debug@rivosinc.com wrote:
>>envcfg CSR defines enabling bits for cache management instructions and soon
>>will control enabling for control flow integrity and pointer masking features.
>>
>>Control flow integrity and pointer masking features need to be enabled on per
>>thread basis. Additionally, I believe cache management instructions need to be
>>enabled on per thread basis. As an example a seccomped task on riscv may be
>>restricted to not use cache management instructions
>
>Do we have anything in the kernel that actually does that? Generally
>we need some use, I couldn't find any user-mode writable envcfg bits
>in any extesions I looked at (admittidly just CFI and pointer
>masking), and unless I'm missing something there's no per-thread state
>in the kernel.
>
Cache management operations?
As of now kernel blindly enables that for all the user mode. It will be good if
that is enabled on per-thread basis. Sure, all threads can have it enabled by
default. But if strict seccomp is enabled, I would argue that cache management
operations for that thread to be disabled as is done on other arches. As an
example x86 disable rdtsc on strict seccomp.
RISCV allows this CMO extension and I expect CMO to leverage this (currently it
doesn't).
I was being opportunistic here so that I can reduce number of patches on CFI
enabling patchset.
Will it be okay if I revise this patch to include with a usecase to restrict CMO
(say for case of strict seccomp on risc-v)?
next prev parent reply other threads:[~2023-12-13 1:03 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-12 23:49 [PATCH v1 2/2] riscv: envcfg save and restore on trap entry/exit Deepak Gupta
2023-12-12 23:49 ` [PATCH v1 1/2] riscv: abstract envcfg CSR Deepak Gupta
2023-12-13 0:53 ` [PATCH v1 2/2] riscv: envcfg save and restore on trap entry/exit Palmer Dabbelt
2023-12-13 1:02 ` Deepak Gupta [this message]
2023-12-13 12:24 ` Andrew Jones
2023-12-13 16:27 ` Deepak Gupta
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZXkCs9ypok5X/Wx2@debug.ba.rivosinc.com \
--to=debug@rivosinc.com \
--cc=ajones@ventanamicro.com \
--cc=aou@eecs.berkeley.edu \
--cc=apatel@ventanamicro.com \
--cc=bjorn@rivosinc.com \
--cc=cleger@rivosinc.com \
--cc=conor.dooley@microchip.com \
--cc=evan@rivosinc.com \
--cc=greentime.hu@sifive.com \
--cc=guoren@kernel.org \
--cc=heiko@sntech.de \
--cc=jeeheng.sia@starfivetech.com \
--cc=jszhang@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=mchitale@ventanamicro.com \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=samitolvanen@google.com \
--cc=waylingii@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox