5.13 / 5.14 #60

Yes, because the port is incomplete. Feel free to participate, primarily the "slub: add multi-purpose random canaries" fails during boot.

Should offending patch be temporarily reverted then?

Should offending patch be temporarily reverted then?

This seems to happen with every mainline release. Can anyone speak as to when the last attempt to upstream the overall patchset was? Or any part of it? Time has shown that this is a losing game, with the people left vulnerable for weeks/months being the real losers.

@hyder365 how about you contribute then? I'm sick of all the vampires taking all the work for free without giving back but choose all possibility to cry a river. It's a massive time investment here that im doing on top of my day job for free. Use the LTS tags. If you dont like it, and dont want to contribute to make it better or faster, dont use it.

@Bernhard40 5.13 is nearly finished, test workspaces boot and seem to function, most likely the release will be during the weekend

For the record and for people that really want to help us instead of just complaining, 5.13 is particularly annoying due to KASAN changes – see da844b787245 and d57a964e09c2 — that conflict with SLUB hardenings in linux-hardened. This is actually not the first time. By the way, 5.12 brought KFENCE, which is a bit problematic too especially with slab canaries, and we're still not set on the best way to handle that.

Nowadays I'd say that the bulk of linux-hardened is in mm/slab.h and mm/slub.c, so you could start by looking at what patches do to those files. The more people understand these changes, the more they can help us for each rebase and the quicker linux-hardened will be ready after each mainline release.

We're doing what we can to maintain this patchset, when we have time for it. People that are not satisfied with this work and don't help can always fork linux-hardened or just stop using it and go back to running vanilla, but they're not entitled to anything here.

We have finished and synced up the remaining work for 5.13. I have tagged an RC1 pre-release which I will give some more real world workload (and invite for a quick test) before moving on to stable releases.

https://github.com/anthraxx/linux-hardened/releases/tag/5.13-hardened1-rc1

I've built kernel 5.13.12 with your 5.13-hardened1-rc1 patch, but the system (a VM booting in BIOS mode) hangs without any error message immediately after booting. I'm unsure if this is expected/a known issue or not, or if I'm overlooking something, so I figured putting a comment about it into here wouldn't hurt. :)

I've built the kernel using archbuild from the devtools package with testing repos enabled, using the current linux-hardened PKGBUILD from Archlinux with the following additional changes:

• patch line SUBLEVEL = 0 changed to SUBLEVEL = 12

• https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/queue-5.13/mtd-cfi_cmdset_0002-fix-crash-when-erasing-writing-amd-cards.patch (applied prior to your 5.13-hardened1-rc1 patch)

• export MAKEFLAGS="${MAKEFLAGS} -j16"

• unchanged config compared to 5.12.17/5.12.19 (but the config gets obviously updated automatically during the build process)

@hardfalcon can you check with CONFIG_SLAB_CANARY disabled? If that works, can you check vanilla 5.13.12 with the slab canary patch cherry-picked?

on a debian 11 with gcc version 10.2.1 it is working fine!
Thank you

FWIW, don't know if this will help @hardfalcon, but the INIT_ON_FREE_DEFAULT_ON option was causing my 5.13.12 kernel not to boot, though I can't say for certain that there wasn't something else possibly conflicting with it.

@h4xor666 both have the very same root cause. disabling init_on_free just doesn't overwrite the canary with zero. The latest rc2 addresses this issue and should work with SLAB_CANARY and INIT_ON_FREE_DEFAULT_ON
https://github.com/anthraxx/linux-hardened/releases/tag/5.13-hardened1-rc2

sorry to say, rc2 ist not working for me. I can't see any message, boot process fails after os welcome message

edit: forgot to say, that it's a kvm based virtual machine and os is Debian 11 (bullseye)

Sadly, no luck with rc2. Only thing I changed was the init_on_free_default_on option, still won't boot. I'll try and find logs of some sort.

@karesmakro @h4xor666 please try rc3 🐈

my system was booting successfully! No problems so far.