From: Luis Gerhorst <luis.gerhorst@fau.de>
To: Lukas Gerlach <lukas.gerlach@cispa.de>
Cc: <pjw@kernel.org>, <ast@kernel.org>, <bjorn@kernel.org>,
<bpf@vger.kernel.org>, <daniel.weber@cispa.de>,
<daniel@iogearbox.net>, <jo.vanbulck@kuleuven.be>,
<linux-riscv@lists.infradead.org>, <luke.r.nels@gmail.com>,
<marton.bognar@kuleuven.be>, <michael.schwarz@cispa.de>,
<palmer@dabbelt.com>, <xi.wang@gmail.com>
Subject: Re: [PATCH] riscv, bpf: add a speculation barrier for BPF_NOSPEC
Date: Wed, 07 Jan 2026 09:26:57 +0100 [thread overview]
Message-ID: <87y0m996b2.fsf@fau.de> (raw)
In-Reply-To: <20260106084410.94496-1-lukas.gerlach@cispa.de> (Lukas Gerlach's message of "Tue, 6 Jan 2026 09:44:10 +0100")
Lukas Gerlach <lukas.gerlach@cispa.de> writes:
> I have not benchmarked fence.i in the eBPF context specifically, but
> from my other work on Spectre mitigations on RISC-V I can confirm that
> fence.i flushes the instruction cache on all cores I have tested, both
> in-order and out-of-order, so there is a performance impact.
>
> I agree that making this conditional similar to ARM64's proton-pack.c
> is the right approach. Getting this infrastructure in place is a good
> idea regardless, as the RISC-V hardware landscape is very diverse, and
> we will likely need conditional mitigation support for other Spectre
> defenses as well.
Thanks for the patch, I believe this approach makes sense.
For eBPF, you can make them conditional by implementing
bpf_jit_bypass_spec_v1/v4() similarly to how powerpc does it [1]. They
default to false for archs that do not implement them. Setting them will
not only avoid the performance bumb, but also speed up verification and
improve expressiveness (i.e., fewer programs are rejected for some edge
cases).
I am not familiar with RISC-V, but could the be any problem from fence.i
being an extension [2]? Or do all RISC-V CPUs supported by the kernel
implement this?
[1] https://lwn.net/ml/all/20250603211318.337474-1-luis.gerhorst@fau.de/
[2] https://docs.riscv.org/reference/isa/unpriv/zifencei.html
next prev parent reply other threads:[~2026-01-07 8:35 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-28 17:37 [PATCH] riscv, bpf: Emit fence.i for BPF_NOSPEC Lukas Gerlach
2026-01-05 23:28 ` Paul Walmsley
2026-01-06 8:44 ` [PATCH] riscv, bpf: add a speculation barrier " Lukas Gerlach
2026-01-07 8:26 ` Luis Gerhorst [this message]
2026-01-07 9:54 ` [PATCH] riscv, bpf: Emit fence.i " Lukas Gerlach
2026-01-07 17:52 ` Luis Gerhorst
2026-01-07 23:30 ` Samuel Holland
2026-01-08 10:05 ` Luis Gerhorst
2026-01-09 3:41 ` Bo Gan
2026-01-09 5:36 ` [tech-speculation-barriers] " Stefan O'Rear
2026-01-12 16:19 ` Luis Gerhorst
2026-01-12 18:33 ` Bo Gan
2026-01-13 1:51 ` Paul Walmsley
2026-01-15 13:13 ` Lukas Gerlach
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=87y0m996b2.fsf@fau.de \
--to=luis.gerhorst@fau.de \
--cc=ast@kernel.org \
--cc=bjorn@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel.weber@cispa.de \
--cc=daniel@iogearbox.net \
--cc=jo.vanbulck@kuleuven.be \
--cc=linux-riscv@lists.infradead.org \
--cc=lukas.gerlach@cispa.de \
--cc=luke.r.nels@gmail.com \
--cc=marton.bognar@kuleuven.be \
--cc=michael.schwarz@cispa.de \
--cc=palmer@dabbelt.com \
--cc=pjw@kernel.org \
--cc=xi.wang@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