Re: Fwd: The Upcoming Core Update(s)

Re: Fwd: The Upcoming Core Update(s)

[Arne Fitzenreiter]

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

Am 2024-01-06 13:59, schrieb Peter Müller:
> -------- Weitergeleitete Nachricht --------
> Betreff: Re: The Upcoming Core Update(s)
> Datum: Fri, 24 Nov 2023 13:31:00 +0000
> Von: Peter Müller <peter.mueller(a)ipfire.org>
> An: Michael Tremer <michael.tremer(a)ipfire.org>, Arne Fitzenreiter 
> <arne_f(a)ipfire.org>
> Kopie (CC): IPFire Development <development(a)lists.ipfire.org>
> 
> 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
This is not found because it is disabled by the kernel developers 
because they run a still open gcc bug.
depends on ! CONFIG_CC_IS_GCC

>> <snip>
>> CONFIG_SHADOW_CALL_STACK                |kconfig|     y      |   kspp  
>>  | self_protection  | FAIL: "is not set"
i will test this.

>> CONFIG_KASAN_HW_TAGS                    |kconfig|     y      |   kspp  
>>  | self_protection  | FAIL: is not found
Our selected target cpu doesnt support this.

Arne