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