6:57 a.m.
From: Alice Mitchell on gitlab.com
Merge Request: https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1603
NOTE: Truncated patchset due to missing public @redhat.com email
address on your GitLab profile at https://gitlab.com/-/profile.
Once that is fixed, close and reopen the merge request to
retrigger sending the emails.
This is to add a new kernel taint flag that indicates that this
is a Partner Supported GPL module and not directly Supported
by Red Hat, as per the policy document for partner Supported
upstream kernel modules as linked from the bugzilla.
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2038999
Upstream Status: RHEL only
Signed-off-by: Alice Mitchell <ajmitchell(a)redhat.com>
---
fs/afs/main.c | 3 +++
include/linux/panic.h | 2 +-
kernel/panic.c | 2 +-
kernel/rh_messages.c | 30 ++++++++++++++++++++++++++++++
4 files changed, 35 insertions(+), 2 deletions(-)
7:37 a.m.
From: Alice Mitchell on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1603#note_8357...
I can't post the full policy as it's an internal document, so I shall try my
best to summarise it.
this relates to restrictions to the crypto offload API that have been
inherited from upstream, as I understand it in order to access these APIs a
module needs to have been built and signed as part of the kernel build, which
already happens for fedora, but to do so in RHEL adds a support burden we lack
the resources for.
The negotiated solution which forms the basis of this policy is that :
- The kernel module would be enabled in kernel-ark for future RHEL and centos-
stream builds.
- There will be a new taint flag, “Partner supported GPL kernel module” to
indicate that Red Hat does not support this module. and an accompanying kbase
article explaining this.
- Partner provides support and development effort for their kernel module via
the usual centos-stream process, including CI tests
- The built and signed module would be provided in binary form (not an rpm) to
the partner as the RPM contains metadata like changelog that may contain
sensitive data such as a mention of an embargoed CVE
8:59 a.m.
From: pjgeorg on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1603#note_8358...
Thanks for the info!
I never heard of a crypto offload API with the described restrictions.
Especially as I recently prepared a kmod-kafs to be released by the Kmods SIG
for CentOS Stream 9 and haven't run into such issues. I stopped working on it
once I got word about it being enabled in CentOS Stream 9 upstream. Now I know
how :smile:
Anyway the reason why the policy was first introduced is not important. The
info that such a policy exists is very interesting. Thanks!
Remains the question who may qualify as a _partner_. But I don't dare to ask
you this question. This is very likely the wrong place for such questions.
11:16 a.m.
From: Alice Mitchell on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1603#note_8361...
Oh I very probably got confused over what actually happened, I don't work in
that area at all, something to do with not being able to use a proprietary
module any more so needing a GPL module we didn't and wouldn't support to be
properly signed. As for what constitutes a partner I can't help you there
sorry, that stuff is way above my pay grade. 😁
1:07 p.m.
From: Don Zickus on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1603#note_8362...
@pjgeorg - I wouldn't suggest using this bit. Instead, depending on your
needs, I would suggest using another bit for 'SIG_SUPPORTED' or something very
similar. There is like 6 more bits to use and we rarely use them, so I think
it is safe to propose a new one that provides a clearer definition of what you
need.
The PARTNER_SUPPORTED bit has a lot of strings attached that might delay
support if the module isn't registered with RH support correctly.
@prarit - thoughts on above? who can help here?
5:24 a.m.
From: Alice Mitchell on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1603#note_8417...
Is there anything I should be doing to help make progress on this request?
thanks
5:51 a.m.
From: pjgeorg on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1603#note_8418...
@ajmitchell This request/discussion is not really related to your MR and hence
should be discussed somewhere else. In any case it should not delay your MR. I
have just been curious about this MR and possible implications. @dzickusrh
already suggested to not use this for my intentions and I agree with his
arguments.
10:42 a.m.
From: Patrick Talbert on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1603#note_8422...
Hi all. This thread is technically "blocking" the MR from being merged. Since
it does not appear to be be discussing a fault/issue with the MR code I will
go ahead and mark this thread as resolved. If you would like to continue the
discussion I would suggest the fedora kernel list
(https://lists.fedoraproject.org/admin/lists/kernel@lists.fedoraproject.org/)
or opening an issue here (https://gitlab.com/cki-project/kernel-ark/-/issues).
Keep in mind at this moment the MR still needs to be reviewed and Approved by
the appropriate people before it can be merged.
11:53 a.m.
From: Prarit Bhargava on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1603#note_8423...
Blocking based on the discussion I have started in the bugzilla.
8:51 a.m.
From: Prarit Bhargava on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1603#note_8526...
Unblocking this :)
3:17 a.m.
From: Patrick Talbert on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1603#note_8664...
@ajmitchell The `os-build` branch is rebased whenever there is an official
release of the upstream kernel. This is expected to next happen this coming
Monday, the 14th. So just be aware if this MR is not ready for merge by then
that it will need to be rebased.
773
days inactive
801
days old
kernel@lists.fedoraproject.org
10 comments
5 participants
participants (5)
-
Alice Mitchell (via Email Bridge) -
Don Zickus (via Email Bridge)
-
Patrick Talbert (via Email Bridge)
-
pjgeorg (via Email Bridge)
-
Prarit Bhargava (via Email Bridge)