Tetragon security model ?

The LWN writeup is phrased to say they're using Tetragon for detection, not for mitigation. That is, they're trying to find signs that a vulnerability was invoked or an unwanted privilege escalation occurred, but they're not expecting the compromised kernel to be able to fully defend itself against the exploit. Once they know about a vulnerability, the system that this article is about is used to prevent further exploitation on other systems in the first place, which is the approach the grsec article recommends.

I suppose it's possible that a sufficiently skilled exploit could turn off reporting, but I think this basically turns into a race condition - whether the malicious code can kill the reporting codepath before it manages to fire a packet off - and this is now biased in favor of the defender. Race conditions are not a great answer when trying to prevent exploitation, since a single successful exploit is a win for the attacker. But they're a much better answer if you're simply trying to detect it, since a single unsuccessful exploit is a win for the defender, who now knows they have something to respond to. So, if the exploit is some non-deterministic thing that is mostly stymied by ASLR, then a single report of malicious code having run and failed to secure a foothold is enough.