On Thu, May 21, 2026 at 7:38 AM Sasha Levin <[email protected]> wrote: > > On Tue, May 19, 2026 at 03:00:15PM -0700, Song Liu wrote: > >On Tue, May 19, 2026 at 12:57 PM Sasha Levin <[email protected]> wrote: > >[...] > >> >Fully agree with Song here that there is no clear boundary, and that the > >> >killswitch could lead to arbitrary, hard to debug breakage if applied to > >> >the wrong function.. introducing worse bugs than the one being mitigated > >> >or even /short-circuit LSM enforcement/ (engage security_file_open 0, > >> >engage cap_capable 0, engage apparmor_* etc). > >> > >> This is similar to livepatch, right? Do we need guardrails there too? > > > >livepatch has the same guardrails as other kernel modules: > >CONFIG_MODULE_SIG, CONFIG_MODULE_SIG_FORCE, etc. > > Which the user can choose to enable or disable. Livepatches will work just > fine > with CONFIG_MODULE_SIG=n, right? > > With the whitelist approach, the user has no choice but to accept it. > > Would it make sense to allow disabling the whitelist via a kernel config or > some runtime flag?
I personally think it makes sense to have options to allow bypassing/blocking more kernel functions than the current allow list. But I don't know whether we would like to go all the way to allow it for all the ftrace-able functions. I think we will need some careful analysis on this. Thanks, Song
