Re: [PATCH v3] killswitch: add per-function short-circuit mitigation primitive

On Thu, May 21, 2026 at 11:16:46AM -0700, Song Liu wrote:
>On Thu, May 21, 2026 at 8:31 AM Sasha Levin <[email protected]> wrote:
>>
>> On Thu, May 21, 2026 at 11:11:16AM +0200, Daniel Borkmann wrote:
>> >On 5/19/26 9:57 PM, Sasha Levin wrote:
>> >>Sure, this would also work. How do you see this happening? Can we let a certain
>> >>user/pid/etc disable the allowlist if they choose to?
>> >
>> >I don't think we should, given then we're back to square one where root
>> >or some other user would be able to just override/bypass an LSM.
>>
>> killswitch already disables itself when lockdown is active. We can easily
>> disable it too when one of the LSMs that cares about this is active.
>>
>> >[...]
>> >>How do you see this working with the allowlist?
>> >
>> >We should look at the underlying areas where most of the CVE-like fixes
>> >took place (these days should be more easily doable given Claude and friends)
>> >and based on that either extend ALLOW_ERROR_INJECTION() or (better) create
>> >new hooks which BPF LSM can consume where you can then have a policy to reject
>> >requests and tighten the attack surface. For example, the AF_ALG stuff you
>>
>> So we could grow the LSM tentacles deeper into the kernel, and we can see where
>> current CVEs are happening, which I suspect is the darker corners of the kernel
>> (old unmaintained, rarely used code), but this definitely won't stay the case,
>> right? Newer and better LLMs will discover issues elsewhere, and once the low
>> hanging fruits are picked off of the current target subsystems, researchers
>> will move elsewhere. We will be dooming ourselves to an endless cat and mouse
>> game where we go add LSM hooks after some big security issue goes public.
>
>Do we really need to add new LSM hooks for recent CVEs?
>
>The LSM hooks are designed to cover all the user-kernel interfaces. Then
>with properly designed policies, we should have coverage for potential CVEs.
>Existing LSM hooks may not be perfect, but we can improve the hooks,
>potentially with the help of smart LLMs, so that these hooks can cover
>future security issues. In some cases, we will need new policies, but I don't
>think new hooks will be needed for most of these CVEs.

Running a quick LLM evaluation on the last ~70 severe CVEs, it seems that about
40% is doable with the current hooks.

-- 
Thanks,
Sasha