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

On 5/23/26 3:41 PM, Sasha Levin wrote:
> 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.


Interesting, do you have some more details in which areas your eval sees new
lsm hooks missing?