Add kernel-6.1 sources and use it for -dev variants #3121
Conversation
|
The three failing checks are expected to fail with me not having uploaded the srpm to the lookaside cache. I am hesitant to do that until we have some more clarity on pushing this out. SELinux I will have to do some extra dive there. I do not have a lot of experience on getting these together and both new classes seem to be not similar to any other classes to model them after that. The new classes have been introduced as follows:
While poking around I have also found that the |
|
Added the new SELinux classes. I am not quite sure if we would want to further restrict the access/use of these generally. Particularly the user_namespace one might be interesting here. |
|
For orchestrated containers, the SELinux policies permissions are "relaxed", meaning that they are granted almost all permissions since we don't know what users are doing in their workloads. For |
|
I've got to review this in batches, but you made it easy to do so. :-)
|
This one only has an impact on the VMware variant. For metal and AWS variants we explicitly set the ones we need there. The table shows an x only in the vmware-variant's column. If we need this one for vmware, we can add it back. Given that we did not explicitly enable it there before I would have thought we are good leaving it out.
Good point, will have a discussion with Al team on why they dropped this.
Working through all these i was under the impression that it would allow to encrypt and not force encryption by default. Re-reading this now I come to the same conclusions as you. |
Agree, everything is as it should be. I totally missed this only affects the VMware build.
Yes, that's the case: Users can opt into encrypting individual directories if the filesystem supports this. Since ext4 (the current file system for the data partition) supports per-file encryption but e.g. XFS does not, I was worried that exposing this feature might get users stuck with ext4. I since looked into this some more and per-file encryption does not work through overlayfs (yet?). That lessens the concern somewhat, though it may at become relevant again in the future. For situations where the filesystem is under user control, like ephemeral disks or EBS volumes, dm-crypt seemed like a better choice. Unexplainable changes (5/468 config changes):
Architecture and toolchain specific changes (72/468 config changes):
New drivers that are not needed (85/468 config changes) |
|
New functionality I am confident we do not need (47/468 config changes): Looks good to me. General config cleanup (197/468):
The uninteresting remainder (15/468): Looks good to me. |
There was a problem hiding this comment.
Some additional notes:
- I tested kdump still works.
- Would be good to test building an out-of-tree module using the still works.
- I'll have to defer judgement on the semantics of the SELinux changes, alas. Is my interpretation correct that everything is being allowed to use the mentioned io_uring features and create user namespaces (still blocked via sysctl)?
packages/kernel-6.1/1003-initramfs-unlink-INITRAMFS_FORCE-from-CMDLINE_-EXTEN.patch
Outdated
Show resolved
Hide resolved
|
Above force push tended many of the comments. Still need to clean up the |
|
Latest force-push was to rebase on top of current |
|
The new change disabling FS_ENCRYPTION had the expected results disabling |
|
This is probably on your radar, but we should also add the qlen patch to 6.1. |
I'm fine with disabling these.
No concerns as long as Lustre comes back.
The FIPS selftest sounds like something we might want or need. It might be OK if it has a negligible impact on boot time.
+1
Should we be setting
+1
It seems like we had Do we need the
+1 If it's creating delta from the Amazon Linux kernel config, we could potentially drop these items: I.e. we don't need or want the modules if they're disabled altogether in recent AL kernels. |
We had to roll this back due to old user space not supporting zstd. Unfortunately, even with |
Signed-off-by: Leonard Foerster <foersleo@amazon.com>
Signed-off-by: Leonard Foerster <foersleo@amazon.com>
In linux 5.16 new io_uring related access controls were added to SELinux. Add the new class and the new permission into the blanket "systems" permission set, to not add new SELinux restrictions. Signed-off-by: Leonard Foerster <foersleo@amazon.com>
In linux 6.1 new user_namespace related access controls were added to SELinux. Add the new class and the new permission into the blanked "systems" permissions set, to not add new SELinux restrictions. Signed-off-by: Leonard Foerster <foersleo@amazon.com>
Amazon Linux enabled FS_ENCRYPTION with the introduction of kernel-6.1. With Bottlerocket, that might lock us into certain file system choices inadvertantly. Disable it for now and rely on block level encryption through EBS volume encryption or dm-crypt instead. Signed-off-by: Leonard Foerster <foersleo@amazon.com>
[port from kernel-5.15: ddc0757] Increase the kernel's default value for the net.unix.max_dgram_qlen sysctl to 512. This is a change to the kernel rather than a plain sysctl setting since systemd-sysctl only applies settings to the host, while the changed default value in the kernel also applies to every new network namespace. Signed-off-by: Markus Boehme <markubo@amazon.com> Signed-off-by: Leonard Foerster <foersleo@amazon.com>
For most NICs we have been going with the bare driver without any additionally configurable features. With the 6.1 kernel we pick up additional features for the already included ICE driver. Disable these features as we have done for other NICs before. Signed-off-by: Leonard Foerster <foersleo@amazon.com>
We currently do not have a use case for the DAMON subsystem. Disable it for now to trim some code we build. If we come across a use case we can add it into our config. Signed-off-by: Leonard Foerster <foersleo@amazon.com>
|
Latest push includes following adjustments:
|
|
Happy to stay completely out of the way and not pollute your PRs, but we're very excited for this. We've been waiting for a while to be able to properly use If you need real-life customer testers, I volunteer. |
|
Sorry for the potentially inappropriate post on this PR, but what's a good way to test the dev/6.x builds? 🫠 |
It is absolutely not inappropriate at all. We are extremely happy when people want to test and extend their helping hands in the project overall. Thank you for offering your time. Unfortunately, we currently do not have a great way to supply you with AMIs for testing. Additionally the I currently have a testing commit for nvidia-variants that aids me in testing the new kernel on those platforms for a subsequent PR enabling the new nvidia kmods. You should be able to do something similar to that to get a variant of your choice working with the 6.1 kernel for testing. You can find that commit on my fork. Instructions for building are in BUILDING.md. Feel free to reach out if you have any further questions or need any assistance. |
|
Thank you @foersleo !! |
Issue number: #2855
Description of changes:
Add the sources for Linux kernel-6.1 and enable it for all the dev variants.
The following todo list does not block review of what is already there (config analysis) and will be added soon.
TODO:
user_namespaceandio_uring(See Testing section below)Testing done:
aws-devimage and see it booting successfully with the correct kernel:As expected with a major kernel update there is lots of changes to the kernel config. I have tried to organize them into buckets for easier consumption and review. All changes that can be mapped to a specific commit and upstream series have been annotated with the corresponding data and a short summary has been added to all options.
The change buckets are (ordered by decreasing interest):
ICEas we have done for other NIC drivers. Details in diff_disable.csvTerms of contribution:
By submitting this pull request, I agree that this contribution is dual-licensed under the terms of both the Apache License, version 2.0, and the MIT license.