Hello Peter,
On 24 Nov 2023, at 13:31, Peter Müller peter.mueller@ipfire.org wrote:
Hello Arne, hello Michael,
Hello Arne,
On 23 Nov 2023, at 08:22, Arne Fitzenreiter arne_f@ipfire.org wrote:
Am 2023-11-05 14:15, schrieb Michael Tremer:
Hello everyone, Since this month’s video conference has been canceled, here is a couple of updates from my side:
- Core Update 181 has been branched yesterday. I have this running in my office for a little while and it seems to be a solid update. It also has a lot of security fixes, so please give it a good test that we can hopefully release this in two weeks.
- For the following update(s): what do we have in the pipeline? Just to coordinate that we don’t have too much in one update :)
Best, -Michael
I have grub-2.12-rc1 and i build a kernel update to 6.6.x which looks good. I plan for core183... We should consider to change the IPFire version number because if you update from older versions it load 1.5GB at once before install it.
Yes, I am happy to do this. It is kind of overdue and in this step we should consider taking all legacy versions from the server.
I agree. Is there anything beyond the ipfire-2.x Git repository that needs to be done for this? If so, information on that would be appreciated, so I can take care of this for Core Update 183.
@Arne, on the note of a kernel update: kconfig-hardened flags a couple of architecture-/hardware-dependend kernel configure knobs in the 64-bit ARM configuration that could be set to more secure values. Could you have a look at the following ones, and decide if we can enable them?
$ ./kernel-hardening-checker -c ipfire-2.x/config/kernel/kernel.config.aarch64-ipfire -m show_fail [+] Special report mode: show_fail [+] Kconfig file to check: ipfire-2.x/config/kernel/kernel.config.aarch64-ipfire [+] Detected microarchitecture: ARM64 [+] Detected kernel version: 6.1 [+] Detected compiler: GCC 130200 ========================================================================================================================= option name | type |desired val | decision | reason | check result =========================================================================================================================
<snip> CONFIG_ARM64_BTI_KERNEL |kconfig| y |defconfig | self_protection | FAIL: is not found <snip> CONFIG_SHADOW_CALL_STACK |kconfig| y | kspp | self_protection | FAIL: "is not set" CONFIG_KASAN_HW_TAGS |kconfig| y | kspp | self_protection | FAIL: is not found
To the best of my understanding, CONFIG_ARM64_BTI_KERNEL would enable indirect branch tracking for the kernel space (enabled by default on x86_64), and CONFIG_SHADOW_CALL_STACK and CONFIG_KASAN_HW_TAGS make use of some hardware feature that is only available on 64-bit ARM.
I would like to highlight that shadow call stacks only work when they are actually compiled into the binaries as well. That means, that we will have to re-ship the entire distribution to make this feature actually work. It is not enough to just enable this in the kernel.
The same goes for branch protection.
Are you going to have a look at that?
-Michael
Thank you in advance for having a look, and best regards, Peter Müller