1. Please include information about performance impact.
1. Performance issues are related to |net.core.bpf_jit_harden| in specific use
cases, although those are unlikely to apply to Fedora. I work with
bpf_jit_harden=2 for weeks without any measurable impact. Zbigniew
Jędrzejewski-Szmek also posted something about this in the Discourse topic. A
performance impact would apply only to use cases that create massive
passthrough in BPF_JIT in the affected privilege level, which I expect is not
realistic in use cases of Fedora but more of specific use cases of RHEL or Alma
or so, potentially even more specialized systems. For us, these seem minor
occurrences at which I could not identify one that makes noteworthy amount of
computation on Fedora.
E.g., I could imagine if you write a script that creates with all available performance
"firejailed" sandboxes of an application (so not use a firejail sandbox but create
persistently new ones with all capacity), then you might be able to measure a difference
with and without bpf_jit_harden, because each sandbox creation will provoke SECCOMP-BPF
instructions to be processed by BPF_JIT, but even in that use case I have doubts that the
computation share of bpf_jit will make a noteworthy difference compared to the overall
computation of the tasks (keep in mind that this will not affect the performance of the
firejail sandbox at all but only the tasks that involve SECCOMP-BPF instructions) -> I'm
sure we agree that this is not a use case.
Servers that do massive filtering related to bpf_jit might be affected to a
measurable amount, but again, I don't think this is a use case for Fedora.
Cilium (see sources) also contains information related to performance (e.g.,
even with enabled bpf_jit_hardening, performance of the bpf jit compiler still
outcompetes the bpf interpreter). In short, all use cases I found that might
create a noteworthy/measurable performance impact are likely to be use cases
that (hopefully) will take place only on enterprise(-like) grade OS with LTS
kernels...
------
> 2. Disabling debug for non-root users is 100% NO-GO for me, as it will make
Fedora unusable for development. It would also break abrt, which is used for bug
reporting.
Yes, that was buried in the wall of text. Disabling gdb for non-root users
(even if it could be enabled) is definitely not good.
2. & subsequent post: This (ptrace_scope & necessary documentation & origins of the current state) was a core element elaborated at different places, along with how to create the documentation and why. Also, keep in mind that it was considered to make this a security update separate from my proposal because the reason ptrace_scope became 0 was an accident, and actually an improvised and unapproved "effectively/finally system-wide" change -> it became no security update as it is not time-critical and part of the proposal anyway. So keep in mind that even if the proposal is rejected, the ptrace_scope=1 has a high chance to come, or alternatively affected developers who think it needs to be 0 by default would need to create a new proposal that achieves an approved disabling of ptrace_scope. I don't know how FESCo would do a "minimalistic" security update about this, and if that would keep the mentioned package (which means gdb & strace-containing systems are again by default
ptrace_scope=0) or not (given that we cannot exclude this type of "accident" to happen again -> making the package effectively a systemwide dependency & thus disabling ptrace_scope accidentally on all Fedoras at all again), but achieving to keep ptrace_scope 0 might be something that goes even beyond rejecting the proposal (see also the original topic). Just to make you aware.
However, in any case, you will still be able to use gdb and strace. But with
the assumption that the majority of user groups will not need ptrace_scope=0
while many of them belong to vulnerable groups, it will be developers who just
need to use one command to temporarily set it to 0, or add one line to achieve
it permanently. Also, that way people including developers can make themselves
the decision if they want it permanently or temporarily. What I propose is
actually what people who were affected by this problem in the first place asked
for: an easy to find documentation that tells them what is going on and how to
migitate. The proposal and the Discourse topic were already updated with a
(Docs approved) suggestion on where and how to do the documentation and release
notes. I'm happy to optimize if you have ideas of course.
Please read the proposal (and at this time some posts from others incl. developers) before
posting things like that: it is not realistic to assume that Fedora becomes
"unusable" for developers because of that -> I'm sure there are developers
using Arch Linux and openSuSE and Ubuntu, and for them ptrace_scope=1 is already the default
for years. It is indeed a matter of debate if ptrace_scope should be 1 or 2, but I expect
for most developers, becoming active the way elaborated in the proposal and the discussions
is more or less the same. 1 might avoid the need to become active for developers who are
only working with child processes of gdb/strace.
-----
These things are largely already tackled in the Discussion topic. Please
respond and post there, so that the discussion remains consistent and avoid
redundancy. Also, if you have ideas about how to optimize the Docs or so, do it
in Discourse as well. I now focus my efforts there. I hope you understand :)
Best,
Chris
On 11/09/2025 21.27, Richard W.M. Jones wrote:
On Thu, Sep 11, 2025 at 09:04:46PM +0200, Vitaly Zaitsev via devel wrote:
2. Disabling debug for non-root users is 100% NO-GO for me, as it
will make Fedora unusable for development. It would also break abrt,
which is used for bug reporting.
Yes, that was buried in the wall of text. Disabling gdb for non-root
users (even if it could be enabled) is definitely not good.
Rich.
--
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
