On Mon, May 11, 2026 at 09:41:07AM -0400, Sasha Levin wrote: > On Mon, May 11, 2026 at 06:14:27AM -0700, Breno Leitao wrote: > > helo Sasha, > > > > First of all, Thanks for this feature, this is useful to me, and I am > > interested in it. Feel free to copy me and I can test the next revisions > > > > On Fri, May 08, 2026 at 03:57:48PM -0400, Sasha Levin wrote: > > > > > +config KILLSWITCH > > > + bool "Killswitch: short-circuit a kernel function as a CVE mitigation" > > > + depends on SECURITYFS > > > + depends on KPROBES && HAVE_KPROBES_ON_FTRACE > > > + depends on HAVE_FUNCTION_ERROR_INJECTION > > > + select FUNCTION_ERROR_INJECTION > > > + help > > > + Provide an admin-facing mechanism to make a chosen kernel function > > > + return a fixed value without executing its body, as a temporary > > > + mitigation for a security bug before a real fix is available. > > > + > > > + Operators write "engage <symbol> <retval> [reason]" to > > > > Should [reason] be shown at "engaged" ? I was expecting it, and in fact > > find it > > very useful, but I don't see it. > > > > # echo "engage __x64_sys_getuid 12 CVE-2026-99999-INCIDENT-4242" > > > /sys/kernel/security/killswitch/control > > # cat /sys/kernel/security/killswitch/engaged > > __x64_sys_getuid retval=12 hits=12 > > This was a woopsie on my end: originally I planned to have a reason field, but > then decided to drop it to keep the patch simple. However, I forgot to fix up > the kconfig help text :( > > If you think it'll be useful, I'm happy to add it back.
I see the value in having a reason field, but at the same time this is just a small detail in the grand scheme here. That said, starting with a simpler implementation and adding it later—once the feature sees production use seems like a reasonable approach. Thanks, --breno
