Skip to content

{jallison} add lab ra requested changes #573

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
merged 2 commits into from
Sep 22, 2025
Merged

{jallison} add lab ra requested changes #573

merged 2 commits into from
Sep 22, 2025

Conversation

jallisonciq
Copy link

Add back CRYPTO_TFM_FIPS_COMPLIANCE flag.
Add PCT for DH key generation.

@jallisonciq jallisonciq self-assigned this Sep 15, 2025
@kerneltoast kerneltoast force-pushed the {jallison}-add-lab-RA-requested-changes branch from d22b28c to ca9afe0 Compare September 15, 2025 22:49
@kerneltoast
Copy link
Collaborator

I force pushed {jallison}-add-lab-RA-requested-changes with the original commits for that code, fetched from kernel-ark.

kerneltoast
kerneltoast approved these changes Sep 16, 2025
View reviewed changes
Copy link
Collaborator

@kerneltoast kerneltoast left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🚢

@PlaidCat
Copy link
Collaborator

I need to make sure we get documented a better way of saying where our sources are

Add efi_status_to_str() and rework efi_status_to_err().
jira LE-2629
feature Fedora EFI status status
ommit 7a60169d168d6aae70aca10b7b71070666068529
commit-source https://gitlab.com/cki-project/kernel-ark/

This is what I used when pulling secure boot stuff from Kernel-Ark and Debian 489faf9 or 5486b17
(Yes this needs fixed on the next rebase to be commit)

What i find interseting is that ARK revences CentOS-9 as the source for both with merge requests that have mroe commits.

Now making this spicer is that is Stream-10 (6.12.x)
crypto: seqiv - flag instantiations as FIPS compliant is in there

But crypto: dh - implement FIPS PCT does not appear to be
https://gitlab.com/search?search=%22crypto%3A+dh+-+implement+FIPS+PCT%22&nav_source=navbar&project_id=56169485&group_id=10873929&search_code=true&repository_ref=e21c2482355f25a3898b0612ed39bfc9139eb28a

I would appreciate it if we kept our original formatting on pulled patches commits so probably something like

Summary

JIRA - LE-XYZ (if it exists)
feature FIPS enablement
commit sha or patch name in commit-source
commit-source url to sha / patch (if available)

<Continue original Commit>

I want to make sure that when we do forward ports or rebases we know where and why things came in, in the event we move the kernel again and we lose all the PR data.

@kerneltoast
Copy link
Collaborator

@PlaidCat For the FIPS patches though there's been no precedent of following our commit formatting. The justification for these code changes comes from the lab so the provenance of the code doesn't matter—the lab wants it and all I did was fish out the actual commits for these changes.

@PlaidCat
Copy link
Collaborator

@PlaidCat For the FIPS patches though there's been no precedent of following our commit formatting. The justification for these code changes comes from the lab so the provenance of the code doesn't matter—the lab wants it and all I did was fish out the actual commits for these changes.

Just because there hasn't been precedence because the lab wants them doesn't mean we shouldn't try, there is nothing worse than coming back to something and not knowing where or why we got the stuff from and where we should be looking for updates / changes.

Which is why I said

I need to make sure we get documented a better way of saying where our sources are

@kerneltoast
Copy link
Collaborator

@PlaidCat How should we document the provenance within our standard format? Since these commits don't come from upstream Linux.

@jallisonciq
Copy link
Author

@PlaidCat How should we document the provenance within our standard format? Since these commits don't come from upstream Linux.

Ping. @PlaidCat - if you have time can you respond to this ? It's the last thing we need to get this merged. Thanks !

@PlaidCat
Copy link
Collaborator

Please use this one from here: #573 (comment)

jira LE-2629
feature Fedora EFI status status
commit 7a60169d168d6aae70aca10b7b71070666068529
commit-source https://gitlab.com/cki-project/kernel-ark/

Summary

JIRA - LE-XYZ (if it exists)
feature FIPS enablement
commit sha or patch name in commit-source
commit-source url to sha / patch (if available)

<Continue original Commit>

@kerneltoast
crypto: seqiv - flag instantiations as FIPS compliant
9aea359 
feature FIPS enablement
commit-author Vladis Dronov <vdronov@redhat.com>
commit e3a5a100a7dcd102b45f6b402f3d8b6a3ceabc1c
commit-source https://gitlab.com/cki-project/kernel-ark.git

JIRA: https://issues.redhat.com/browse/RHEL-54183
Upstream Status: RHEL only

Forwardport of 45e87c3 ("crypto: seqiv - flag instantiations as FIPS
compliant") from C9S. This patch has no chances to be accepted upstream,
see the commit message below.

Author: Nicolai Stange <nstange@suse.de>

    crypto: seqiv - flag instantiations as FIPS compliant

    For gcm(aes) with external IV generation, FIPS 140-3 requires the
    verification of all external IV generation operations in order to ensure
    the uniqueness of the IV (see IG C.H). This is being deemed unfeasible and
    thus, only internal IV generation, i.e. wrapping gcm(aes) with seqiv(),
    can effectively be considered as approved.

    The standard approach would be to disallow plain gcm(aes) and to only
    allow seqiv(gcm(aes)) in FIPS mode. However, there are quite some plain
    gcm(aes) usage sites in the kernel: a quick grep reveals samba, macsec,
    ceph, mac80211, tipc, tls, etc. and breaking these in FIPS mode would be
    highly undesirable. It might perhaps be possible to convert some of these
    to seqiv(gcm(aes)), but for some others it might be entirely impossible due
    to e.g. protocol constraints.

    For the time being, an alternative approach has been proposed as a
    workaround: make seqiv() set a new flag, CRYPTO_TFM_FIPS_COMPLIANCE, on the
    transforms and document that in the particular case of gcm(aes), callers
    must check for this flag in order to determine FIPS compliance.

    Implement this.

    Signed-off-by: Nicolai Stange <nstange@suse.de>

	Signed-off-by: Vladis Dronov <vdronov@redhat.com>
(cherry picked from commit e3a5a100a7dcd102b45f6b402f3d8b6a3ceabc1c)
	Signed-off-by: Sultan Alsawaf <sultan@ciq.com>
@kerneltoast
crypto: dh - implement FIPS PCT
b0f0c55 
feature FIPS enablement
commit-author Vladis Dronov <vdronov@redhat.com>
commit 6030c378bf503f83af9d46e58d43e164fa49eaa5
commit-source https://gitlab.com/cki-project/kernel-ark.git

JIRA: https://issues.redhat.com/browse/RHEL-54183
Upstream Status: RHEL only

Forwardport of 8d6b650 ("crypto: dh - implement FIPS PCT") from C9S.

The below patch from Nicolai is not going to be accepted upstream.
Add a panic on a failed test per FIPS certification requirement.

    From: Nicolai Stange <nstange@suse.de>
    Date: Tue, 30 Nov 2021 16:51:12 +0100
    Subject: [PATCH] crypto: dh - implement FIPS PCT
    References: jsc#SLE-21132,bsc#1191256
    Patch-mainline: Never, not upstreamable

    SP800-56Arev3, 5.6.2.1.4 ("Owner Assurance of Pair-wise Consistency")
    requires that a pair-wise consistency check needs to be conducted on a
    keypair. A pair-wise consistency test (PCT) is meant to ensure that a
    some provided public key is indeed associated with the given private one.
    As the kernel's DH implementation always computes the public key from the
    private one, this is guaranteed already as per the API. However, in the
    course of the certification process, there had been a lengthy discussion
    regarding this topic, with the result that a PCT is nonetheless mandatory.
    Simply implement a PCT for DH and move on. As mandated by SP800-56Arev3,
    5.6.2.1.4, the PCT involves recomputing the public key and comparing it
    against the one under test.

    Signed-off-by: Nicolai Stange <nstange@suse.de>

	Signed-off-by: Vladis Dronov <vdronov@redhat.com>
(cherry picked from commit 6030c378bf503f83af9d46e58d43e164fa49eaa5)
	Signed-off-by: Sultan Alsawaf <sultan@ciq.com>
@kerneltoast kerneltoast force-pushed the {jallison}-add-lab-RA-requested-changes branch from ca9afe0 to b0f0c55 Compare September 20, 2025 00:14
@kerneltoast
Copy link
Collaborator

Commit messages updated again. Code is still unchanged from when the PR was originally created.

PlaidCat
PlaidCat approved these changes Sep 22, 2025
View reviewed changes
Copy link
Collaborator

@PlaidCat PlaidCat left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:shipit:

@jallisonciq jallisonciq merged commit 1dee5d1 into {jallison}-ciq-6.12.fipstest Sep 22, 2025
6 checks passed
@jallisonciq jallisonciq deleted the {jallison}-add-lab-RA-requested-changes branch September 22, 2025 17:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@kerneltoast kerneltoast kerneltoast approved these changes

@PlaidCat PlaidCat PlaidCat approved these changes

@jason-rodri jason-rodri Awaiting requested review from jason-rodri

@bmastbergen bmastbergen Awaiting requested review from bmastbergen

@shreeya-patel98 shreeya-patel98 Awaiting requested review from shreeya-patel98

Assignees

@jallisonciq jallisonciq

Labels
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@jallisonciq @kerneltoast @PlaidCat