Killswitch: Per-function short-circuit mitigation primitive • Hacker News Board

Re: Killswitch: Per-function short-circuit mitigation primitive

#11

Post by PeterWhittaker » Sat, May 09, 2026, 2:44 PM UTC

cyanydeez wrote: post #3

PeterWhittaker wrote: post #2

Clever! I know some will say it's like closing the barn door after the horse left, but having this in place to mitigate future vulnerabilities will be handy.

ok, but what kind of nefarious use case will it enable if it is accessible to malfeasance.

I may be wrong, but on a correctly-configured system, one would have to have root access to act nefariously. Since this is intended to prevent exploitation of vulnerabilities that enable privilege escalation, it feels like a net win.

Re: Killswitch: Per-function short-circuit mitigation primitive

#12

Post by luka598 » Sat, May 09, 2026, 4:38 PM UTC

>Assisted-by: Claude:claude-opus-4-7

Re: Killswitch: Per-function short-circuit mitigation primitive

#13

Post by Brian_K_White » Sat, May 09, 2026, 4:53 PM UTC

luka598 wrote: post #12

>Assisted-by: Claude:claude-opus-4-7

As an ai critic myself, so what?

Re: Killswitch: Per-function short-circuit mitigation primitive

#14

Post by Phelinofist » Sat, May 09, 2026, 5:16 PM UTC

Could something like this also be done via BPF?

Re: Killswitch: Per-function short-circuit mitigation primitive

#15

Post by ainto » Sat, May 09, 2026, 6:17 PM UTC

What about inlined functions?

Re: Killswitch: Per-function short-circuit mitigation primitive

#16

Post by Rygian » Sat, May 09, 2026, 6:29 PM UTC

ainto wrote: post #15

What about inlined functions?

As addressed in the article ("Choosing the right target"):

> Pick the *highest-level* entry point that contains the bug

Re: Killswitch: Per-function short-circuit mitigation primitive

#17

Post by tandr » Sat, May 09, 2026, 6:37 PM UTC

frumiousirc wrote: post #4

If I'm a malicious actor that gets root, can I killswitch the killswitch?

Or malloc(), or open()... They kind of discussing it in the thread on how to prevent this from a malicious actor (or from footgunning yourself), but my understanding it is not all that plain and simple...

Re: Killswitch: Per-function short-circuit mitigation primitive

#18

Post by DoctorOetker » Sat, May 09, 2026, 7:17 PM UTC

this sounds simple, but not running a function doesn't on its own mean safe behavior, if the caller code wasn't written keeping in mind this novel potential refusal as an outcome

still i believe this is the right direction

Re: Killswitch: Per-function short-circuit mitigation primitive

#19

Post by xuhu » Sat, May 09, 2026, 7:18 PM UTC

Is there any library that does this safely for user-mode and is currently used in production ?

Re: Killswitch: Per-function short-circuit mitigation primitive

#20

Post by SwellJoe » Sat, May 09, 2026, 7:19 PM UTC

luka598 wrote: post #12

>Assisted-by: Claude:claude-opus-4-7

The author has an @kernel.org address, and has been a regular Linux contributor for over a decade. I'll give him the benefit of the doubt. It's easy to write high quality AI-assisted code (harder than writing vibe-coded slop, but still easier than writing every line of code yourself).

Edit: This also reminds me that I've begun to judge projects by whether the developer has public code from before AI. I'm more likely to trust their new code. Which causes me concern about the pipeline for new developers...how am I supposed to know a new user on Github has enough understanding of how software works to be shipping software? It used to be that if a new project by a new dev had good docs, some kind of test coverage, and a coherent git history, I could infer some level of quality. Not true, now, so I probably move on and look for something from someone with a pre-AI track record.