Re: The Upcoming Core Update(s)

["Peter Müller" <peter.mueller@ipfire.org>]

[-- Attachment #1: Type: text/plain, Size: 3010 bytes --]

Hello Arne, hello Michael,

> Hello Arne,
> 
>> On 23 Nov 2023, at 08:22, Arne Fitzenreiter <arne_f(a)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.

Thank you in advance for having a look, and best regards,
Peter Müller