From: Herbert Xu on gitlab.com
Merge Request: https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2757
Upstream Status: RHEL only
Restore the changes to /dev/random which were reverted after 5.18.
This reverts commit 900f11e054896bae7b0146055698656e3d1e20a6 and
297bcb88233101e8d5062729ff3a5f989bad1c3b.
This also brings the code up-to-date with respect to centos-stream
commit 9de3a7339793d3c516b9305a8854267156f90c53 so that changes that
were made after the kernel-ark revert have been brought in.
Signed-off-by: Herbert Xu <herbert.xu(a)redhat.com>
---
crypto/drbg.c | 18 ++++-
crypto/rng.c | 149 +++++++++++++++++++++++++++++++++++++++++++-----
drivers/char/random.c | 122 ++++++++++++++++++++++++++++++++++++++++
include/linux/crypto.h | 1 +
include/linux/random.h | 10 +++
5 files changed, 281 insertions(+), 19 deletions(-)
From: Herbert Xu on gitlab.com
Merge Request: https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1304
NOTE: Truncated patchset since committer email 'herbert(a)gondor.apana.org.au'
does not match the submitter's GitLab public email address
'herbert.xu(a)redhat.com'.
Upstream: RHEL only
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1984784
The RHEL FIPS certification effort ran into an show-stopper with
/dev/urandom and getrandom(2) not being FIPS-compliant. At this
point there is no realistic chance of making them FIPS-compliant
upstream. It has also been deemed unrealistic to change user-space
to use the FIPS-compliant RNG through the Crypto API.
Therefore this patch series overrides /dev/*random as well as
getrandom(2) with the Crypto API RNG so that FIPS certification
can proceed.
Signed-off-by: Herbert Xu <herbert.xu(a)redhat.com>
---
crypto/rng.c | 73 ++++++++++++++++++++++++++++++-
drivers/char/random.c | 115 +++++++++++++++++++++++++++++++++++++++++++++++++
include/linux/random.h | 7 ++
3 files changed, 194 insertions(+), 1 deletions(-)
Dear All,
We are academic researchers from Huazhong University of Science and
Technology, China. To foster a healthier Linux kernel community and
enhance the overall security of Linux distributions, we are conducting a
study on kernel security hardening deployments across various Linux
distributions.
In our research, we analyzed kernel config files and the /proc
filesystem by installing and running multiple distribution ISO images.
This allowed us to enumerate the default deployment of kernel defense
mechanisms at runtime.
So far, we have cataloged over 50 kernel security hardening features and
documented inconsistencies in their deployment across different
distributions. The results of our analysis are accessible via the
following link:
https://docs.google.com/spreadsheets/d/17QRr04pqK1K4-VoHXW2-9KgPd4uV8Q4I-NN….
Given Fedora’s reputation for exceptional performance and rich features,
we conducted a detailed investigation into its kernel security hardening
strategies. To further deepen our understanding, we would greatly
appreciate your input on the following questions:
1. Effectiveness of Kernel Security Hardening
1.1 Do you consider deploying kernel security hardening features to
be an effective strategy for ensuring operating system security?
2. Configuration Strategy for Default Kernel Security Hardening Options
2.1 What are the primary criteria for selecting kernel security
hardening options in your distribution?
2.2 How are configurable security hardening features (e.g.,
unprivileged_bpf_disabled) typically set (e.g., 0, 1, or 2), and what
are the main considerations involved?
2.3 How do you balance the trade-off between side-effects (e.g.,
performance overhead) and the enhanced security introduced by kernel
security hardening?
2.4 Does the tolerance for performance overhead vary across
different application scenarios?
2.5 Are there other negative factors, such as compatibility issues,
that are considered when enabling security hardening features?
3. Customized Configurations
3.1 Do you provide different kernel security hardening
configurations tailored to specific user groups?
4. Best Practices and Recommendations
4.1 Are there any best practices or recommendations you can share
regarding kernel security hardening?
4.2 Are there relevant documents or materials available for reference?
The purpose of these questions is to gain a deeper understanding of your
security protection strategies. Your insights would be immensely
valuable to our study.
Thank you for taking the time to review our questions. We look forward
to your response.
Best regards,
Yinhao Hu, PhD candidate
huyinhaodd(a)gmail.com
Huazhong University of Science and Technology
Hey All,
I would like to invite all of you to participate in the Kernel 6.12
Test week is happening from 2024-12-01 to 2024-12-08. It's
fairly simple, head over to the wiki [0] and read in detail about the
test week and simply run the test case mentioned in[1] and enter your
results.
As usual, the Fedora QA team will hangout at #fedora-test-day(a)libera.chat
for questions and discussion.
[0]http://fedoraproject.org/wiki/Test_Day:2024-12-01_Kernel_6.12_Test_Week
[1]https://testdays.fedoraproject.org/events/205
--
//sumantro
Fedora QE
TRIED AND PERSONALLY TESTED, ERGO TRUSTED <https://redhat.com/trusted>