On Wed, 25 Feb 2026 at 23:26, Rik van Riel <[email protected]> wrote: > > On Wed, 2026-02-25 at 21:36 +0100, Marco Elver wrote: > > > > +static int __init early_kfence_fault(char *arg) > > +{ > > + if (!arg) > > + return -EINVAL; > > + > > + if (!strcmp(arg, "report")) > > + kfence_fault = KFENCE_FAULT_REPORT; > > + else if (!strcmp(arg, "oops")) > > + kfence_fault = KFENCE_FAULT_OOPS; > > + else if (!strcmp(arg, "panic")) > > + kfence_fault = KFENCE_FAULT_PANIC; > > + else > > + return -EINVAL; > > + > > + return 0; > > +} > > +early_param("kfence.fault", early_kfence_fault); > > The other parameters in mm/kfence/ seem to be module_param, > which make them tunable at run time through > /sys/module/kfence/parameters/* > > Why is this one different?
That was my first thought too, but after much thought we should not make this changeable after init, see below ... > And, does this one show up as /sys/module/kfence/parameters/fault? > > Having the ability to tweak this behavior at run time, without > requiring a system reboot, could be really useful for people > unexpectedly triggering kernel panics across a fleet of servers, > and deciding they would rather not. It's intentional - having the ability to switch it after init means we'd have to remove __ro_after_init from the kfence_fault setting. We risk having the system administrator's choice being overridden by accident in the exact situation where we do not want it to happen: either through memory corruption overwriting that global flag, or it might give an attacker the ability to circumvent the oops/panic setting, if they manage to reset it. KFENCE is not a mitigation, but this setting is meant to give a knob to reduce the risk that someone takes advantage of KFENCE's heap layout - until now, KFENCE only reports and continues - the actual buggy access happily proceeds.
