From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter =?utf-8?q?M=C3=BCller?= To: development@lists.ipfire.org Subject: Re: The Upcoming Core Update(s) Date: Fri, 24 Nov 2023 13:31:00 +0000 Message-ID: <87911403-ef1a-46f5-bc34-ff01a1bdd798@ipfire.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6591964755978709961==" List-Id: --===============6591964755978709961== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello Arne, hello Michael, > Hello Arne, >=20 >> On 23 Nov 2023, at 08:22, Arne Fitzenreiter wrote: >> >> 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 lo= t of security fixes, so please give it a good test that we can hopefully rele= ase this in two weeks. >>> * For the following update(s): what do we have in the pipeline? Just to c= oordinate that we don=E2=80=99t 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 upda= te 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 shoul= d 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.aarc= h64-ipfire -m show_fail > [+] Special report mode: show_fail > [+] Kconfig file to check: ipfire-2.x/config/kernel/kernel.config.aarch64-i= pfire > [+] 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 | s= elf_protection | FAIL: is not found > > CONFIG_SHADOW_CALL_STACK |kconfig| y | kspp | s= elf_protection | FAIL: "is not set" > CONFIG_KASAN_HW_TAGS |kconfig| y | kspp | s= elf_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=C3=BCller --===============6591964755978709961==--