Hi,
On 12/13/24 10:40 PM, Yinhao Hu wrote:
Hi,
Thank you very much for your detailed response. We sincerely apologize
for the confusion; the data we presented was based on the results from
June 2024, with the specific kernel version indicated at the time. There
is indeed a discrepancy with the latest data. Our intention is not to
highlight or downplay any particular distribution, but rather to
illustrate, to some extent, the impact of kernel security hardening in
real-world scenarios.
The CONFIG_INIT_ON_ALLOC_DEFAULT_ON and CONFIG_RANDOM_KMALLOC_CACHES
were merged upstream through commit IDs
6471384af2a6530696fc0203bafe4de41a23c9ef and
3c6152940584290668b35fa0800026f6a1ae05fe, respectively. These changes
were introduced at least 11 months prior to June of this year.
Interestingly, the Fedora 40 desktop kernel version
(6.8.5-301.fc40.x86_64) has not enabled these security hardening, even
though they are included in the latest Fedora version. Could you help
clarify the reasoning behind the decision to enable these two security
hardenings?
That is the part I'm confused about: You say this is not enabled in F40
despite them being enabled in F41/latest. Which is not true, they _ARE_
currently enabled in F40 as well.
> cat /etc/os-release |grep PRETTY
PRETTY_NAME="Fedora Linux 40 (Workstation Edition)"
> grep ALLOC_DEFAULT_ON /boot/config-`uname -r`
CONFIG_INIT_ON_ALLOC_DEFAULT_ON=y
> grep KMALLOC /boot/config-`uname -r`
CONFIG_RANDOM_KMALLOC_CACHES=y
And have been since April and May.
The changes to enable those two features were done in the fedora kernel
6.9 timeframe. So, by June when the supported kernel was 6.9 you should
have seen them enabled. But as I mentioned in the original comment I
think someone forgot to apply security/etc updates before running your
tests. A release image with the stale kernel was installed, and the
update query was ignored.
Additionally, there seems to be a delay between the upstream
introduction of these security hardenings and their actual
deployment—what factors might be contributing to this delay?
Well in this case it looks like the configuration needed to be manually
enabled.
Fedora tends to follow upstream kernel defaults unless someone manually
reviews/suggests a change. Which to this day upstream defconfigs don't
appear to be enabling some of this stuff without also explicitly
manually enabling the hardening configs. So, it took a fedora maintainer
reviewing and testing the upstream config changes and overriding them
because when the feature first appeared it was default disabled.
Similarly with the generic harding configs.
So if your looking for a 'reason' for a delay in this case, its because
when upstream introduced the feature(s) they didn't think it was
production ready otherwise they would have defaulted it on. For large
features sometimes that is due to perf/ABI/etc tradeoffs and making
large changes to enable features (ex shadow stacks, or BTI) requires
distro maintainers to consider whether the feature works with all
10-100k packages the distro builds/supports. Hence the need for a manual
override.
Particularly cross distro, so many of these things are dictated by when
something is released. Comparing a 5 year old debian vs a bleeding edge
fedora is obviously going to show differences, and that is still there
comparing the latest debian/suse/etc with the latest fedora/leap/etc
simply because of the release date. A couple weeks could be a new
compiler, kernel, glibc, gnome or any number of other things. Distro
maintainers tend to cooperate cross distro, so when a feature appears
simply sorting by distro release date will frequently show nothing more
than a delta between when the feature was created and when it worked
itself into the latest release.
In addition, we also investigated historical versions of Fedora, with
relevant data available at the following link:
https://docs.google.com/spreadsheets/d/1Q2im5w6wwJmzF6TD1OrXMKA3erRpAN-BWVeXtp5i4TY/edit?usp=sharing
From the results, it appears that the security hardening deployment for
the desktop and server editions are almost identical, except for
unprivileged_userfaultfd. Can we conclude that Fedora does not take
different application scenarios into account when enabling its security
hardenings?
Fedora ships a single kernel image across all of the released revisions,
that image changes during the lifecycle of a release.
Again, that image is updated during the product lifecycle, which means
configurations may also change as they did between the original F40
release image and later kernel updates. There are potentially
differences in rawhide, and of course the debug kernels have differing
options. But, the expectation with fedora is that in order to be in a
supported configuration all the latest updates have been applied.
So, you should _not_ be seeing kernel differences between "Workstation"
and "Server" installs of the same vintage unless their updates aren't
applied when a given test is run, and your inadvertently also comparing
different kernels.
On 2024/12/14 3:13, Jeremy Linton wrote:
Hi,
I think its worthwhile to note that the spreadsheet is AFAIK out of date
because I checked for example: CONFIG_INIT_ON_ALLOC_DEFAULT_ON and
CONFIG_RANDOM_KMALLOC_CACHES running an updated F40 and both are enabled.
So, I'm guessing no one ran 'dnf update' before recording the results,
or they are 6+ months old and should probably be updated. That can be
done either with 'dnf update' or by installing/upgrading to F41.
And speaking as a community member I think 1.1 is pretty easy to answer
"yes".
Along the same vein I think reading the discussions around frame
pointers over the past year can provide an idea about how the fedora
community tries to find balance when determining performance/features/
security/etc tradeoffs.
--
_______________________________________________
kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to kernel-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/kernel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
