From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: The Upcoming Core Update(s) Date: Tue, 16 Jan 2024 15:10:20 +0000 Message-ID: In-Reply-To: <87911403-ef1a-46f5-bc34-ff01a1bdd798@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6087681006351439958==" List-Id: --===============6087681006351439958== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello Peter, > On 24 Nov 2023, at 13:31, Peter M=C3=BCller wr= ote: >=20 > Hello Arne, hello Michael, >=20 >> Hello Arne, >>=20 >>> On 23 Nov 2023, at 08:22, Arne Fitzenreiter 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= 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 l= ot of security fixes, so please give it a good test that we can hopefully rel= ease this in two weeks. >>>> * For the following update(s): what do we have in the pipeline? Just 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 goo= d. I plan for core183... >>> We should consider to change the IPFire version number because if you upd= ate 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 shou= ld 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 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 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? >=20 >> $ ./kernel-hardening-checker -c ipfire-2.x/config/kernel/kernel.config.aar= ch64-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 >> =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 | 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 >> >> CONFIG_ARM64_BTI_KERNEL |kconfig| y |defconfig | = self_protection | FAIL: is not found >> >> 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 >=20 > 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 act= ually 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 e= nough 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=C3=BCller --===============6087681006351439958==--