Hello Peter,

On 26 Dec 2022, at 13:22, Peter Müller peter.mueller@ipfire.org wrote:

Hello Michael,

above all, I hope you are doing well, and have/had some restful days.

One tries.

Working through your changes related to the kernel configuration in IPFire 3.x, I took the liberty of backporting some of them (whenever it made sense to do so)

• a patchset will be provided in due course, ideally by tomorrow at the latest.

However, looking at c36f92723a727a1f6366b5d27f5cd2eac106a3cc, the following delta strikes me as implausible to be beneficial for security:

...

-CONFIG_PAGE_POISONING=y +# CONFIG_PAGE_POISONING is not set

Here, you are _disabling_ page poisoning for all architectures in IPFire 3.x, which I doubt is what you intended. For your reference, the current situation in IPFire 2.x is mixed (as usual - sigh):

This was not directly intended, but I noticed that this switch got disabled.

Since we are already trying to wipe all memory pages, what is the point of having this, too?

As far as I understand, all these options are compiled in, but none is then enabled since they all require any kernel command line switches. This is probably the worst design decision since losing a kernel command line is very easy.

-Michael

...

$ grep CONFIG_PAGE_POISONING config/kernel/* config/kernel/kernel.config.aarch64-ipfire:# CONFIG_PAGE_POISONING is not set config/kernel/kernel.config.armv6l-ipfire:# CONFIG_PAGE_POISONING is not set config/kernel/kernel.config.riscv64-ipfire:CONFIG_PAGE_POISONING=y config/kernel/kernel.config.x86_64-ipfire:CONFIG_PAGE_POISONING=y

Thanks, and best regards, Peter Müller