Possible collateral damage while enabling KFENCE In IPFire 3.x

Possible collateral damage while enabling KFENCE In IPFire 3.x

[Peter Müller]

[-- Attachment #1: Type: text/plain, Size: 1144 bytes --]

Hello Michael,

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

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):

> $ 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

Re: Possible collateral damage while enabling KFENCE In IPFire 3.x

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 1722 bytes --]

Hello Peter,

> On 26 Dec 2022, at 13:22, Peter Müller <peter.mueller(a)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