From mboxrd@z Thu Jan  1 00:00:00 1970
From: Arne Fitzenreiter <arne_f@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: Fwd: The Upcoming Core Update(s)
Date: Sat, 06 Jan 2024 21:22:48 +0100
Message-ID: <836b70e985c90fb2f7cc8689b4047b4f@ipfire.org>
In-Reply-To: <77ad230c-eff8-426f-b2e9-43c53fad511f@ipfire.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============9201164547664242332=="
List-Id: <development.lists.ipfire.org>

--===============9201164547664242332==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Am 2024-01-06 13:59, schrieb Peter M=C3=BCller:
> -------- Weitergeleitete Nachricht --------
> Betreff: Re: The Upcoming Core Update(s)
> Datum: Fri, 24 Nov 2023 13:31:00 +0000
> Von: Peter M=C3=BCller <peter.mueller(a)ipfire.org>
> An: Michael Tremer <michael.tremer(a)ipfire.org>, Arne Fitzenreiter=20
> <arne_f(a)ipfire.org>
> Kopie (CC): IPFire Development <development(a)lists.ipfire.org>
>=20
> Hello Arne, hello Michael,
>=20
>> Hello Arne,
>>=20
>>> On 23 Nov 2023, at 08:22, Arne Fitzenreiter <arne_f(a)ipfire.org>=20
>>> wrote:
>>>=20
>>> Am 2023-11-05 14:15, schrieb Michael Tremer:
>>>> Hello everyone,
>>>> Since this month=E2=80=99s video conference has been canceled, here is a=
=20
>>>> couple of updates from my side:
>>>> * Core Update 181 has been branched yesterday. I have this running=20
>>>> in my office for a little while and it seems to be a solid update.=20
>>>> It also has a lot of security fixes, so please give it a good test=20
>>>> that we can hopefully release this in two weeks.
>>>> * For the following update(s): what do we have in the pipeline? Just=20
>>>> to coordinate that we don=E2=80=99t have too much in one update :)
>>>> Best,
>>>> -Michael
>>>=20
>>> I have grub-2.12-rc1 and i build a kernel update to 6.6.x which looks=20
>>> good. I plan for core183...
>>> We should consider to change the IPFire version number because if you=20
>>> update from older versions it load 1.5GB at once before install it.
>>=20
>> Yes, I am happy to do this. It is kind of overdue and in this step we=20
>> should consider taking all legacy versions from the server.
>=20
> 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=20
> appreciated,
> so I can take care of this for Core Update 183.
>=20
> @Arne, on the note of a kernel update: kconfig-hardened flags a couple=20
> of
> architecture-/hardware-dependend kernel configure knobs in the 64-bit=20
> 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?
>=20
>> $ ./kernel-hardening-checker -c=20
>> ipfire-2.x/config/kernel/kernel.config.aarch64-ipfire -m show_fail
>> [+] Special report mode: show_fail
>> [+] Kconfig file to check:=20
>> ipfire-2.x/config/kernel/kernel.config.aarch64-ipfire
>> [+] Detected microarchitecture: ARM64
>> [+] Detected kernel version: 6.1
>> [+] Detected compiler: GCC 130200
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>               option name               | type  |desired val |=20
>> decision |      reason      | check result
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> <snip>
>> CONFIG_ARM64_BTI_KERNEL                 |kconfig|     y     =20
>> |defconfig | self_protection  | FAIL: is not found
This is not found because it is disabled by the kernel developers=20
because they run a still open gcc bug.
depends on ! CONFIG_CC_IS_GCC

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

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

Arne

--===============9201164547664242332==--