> 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 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@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
