-
-
Notifications
You must be signed in to change notification settings - Fork 13.7k
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.
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
Hardened Kernel updates for 2024-09-22 #343751
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This includes updates to hardened kernels we don't support anymore (6.8/...). These should go IMHO.
The unsupported kernels need removing from |
Oh right, that's how it was built. Can you remove the kernels from both files then, please? EDIT: that said, maybe we need a checklist for removing kernels. Always grepping for references is a little annoying and - as it turns out - error-prone. |
36f994d
to
a1c5be5
Compare
Dropped the EOLed kernels from the original PR, then removed from |
Building on |
Result of 75 packages marked as broken and skipped:
66 packages failed to build:
389 packages built:
Not sure which of these are regressions; I’ll try on |
Fwiw the 5.4 hardened tests (
Seems like something failed very early:
5.15/5.10 are fine. EDIT:
In my experience most of these will be hardened issues, not new regressions. |
FWIW: Result of 85 packages marked as broken and skipped:
47 packages failed to build:
599 packages built:
Maybe we should just mark 5.4 broken if it’s causing issues? |
Don't think so, the extensions of the base kernels are also exposed but their broken attribute might need to be set or a maintainer of a specific extension might fix it. Though those have probably been broken for a long time and unrelated to the update |
The issue I see with marking those as broken is that you always have to maintain that list of broken things and for me hardened kernel is something, very few people want (and they know that most of the stuff doesn't build anyways), so I wouldn't want to invest too much time into that. OTOH it would obviously save Hydra from scheduling builds that are known to fail. What I'm wondering is: how many kernel modules to actually build for hardened? Perhaps it's easier to go the other way round and mark everything as broken except for the N things that actually build. |
ZHF is upcoming so maintainers would either fix or have that marked as broken then |
Hi @Ma27, is it ok to merge this as is meanwhile? (Merging is blocked on your requested changes) |
@fabianhjr I don't mind the extensions being broken, but what do we do about the failing 5.4 hardened test? This actually seems like a regression. |
Would like to take a look but focusing on unbreaking some things on the staging-next cycle (of which linux-hardened is part of such breakage) I could target this to staging-next where these are currently not building and would be part of fixing them but I don't think other maintainers would notice that test failure until it landed on main :s |
Oh nvm, not a regression, has been broken since July 28, so two months with breakage |
I mean, I don't expect you to fix it, for me it would be perfectly sufficient to mark 5.4 hardened as broken. This is actually a little dangerous IMHO since it seems to have trouble booting up properly according to the logs I've pasted above. EDIT: that said, I can also take care of this tonight (CEST). |
I wonder if there is really any good reason for us to carry hardened kernels other than for the latest supported release and the latest supported LTS release. I don’t remember if I had a specific rationale at the time other than matching what we already carried in the tree. |
Took the liberty of pushing a fix that marks linux_5_4_hardened as broken. Would later open an issue to discuss what's next to do. |
Due to releases now including a v (and before didn't) hardened hasn't been updated since May 2024 (4 months ago)
Smoketest fails with machine # [ 3.785769] systemd[1]: dev-hugepages.mount: Failed to spawn executor: Argument list too long machine # [ 3.788689] systemd[1]: dev-hugepages.mount: Failed to spawn 'mount' task: Argument list too long machine # [ 3.790100] systemd[1]: dev-hugepages.mount: Failed with result 'resources'. machine # [ 3.791572] systemd[1]: Failed to mount Huge Pages File System.
49c21a7
to
62c09a3
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would like to wait for ofborg and then merge. Thank you for taking care of this.
Thanks @Ma27, sure thing won't merge until eval finishes. Thanks for helping out :3 |
Eval finished, merging |
Description of changes
Last hardened kernel updates: #315121
Things done
nix.conf
? (See Nix manual)sandbox = relaxed
sandbox = true
nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD"
. Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/
)Add a 👍 reaction to pull requests you find important.