Hello Peter, > On 26 Dec 2022, at 13:22, Peter Müller 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