Of course. This is simply a cat and mouse game at this stage. PatchGuard on Windows has the same weakness, and its defense is simply by being implemented through very obscure means. Pretty much every version of Windows has changed the techniques being used, so disabling PatchGuard is very much hitting a moving target.
So yes you could, but you'd have to know it was running in the first place.
The suggestion elsewhere to create an eBPF variant might be interesting to explore.
In closed source you have a bit of leverage (defender advantage) - changes which might be relatively easy for you to implement could take a long time to completely reverse-engineer to the point they can be beaten.
In the open source world, even the design discussions are going to be out in the open.
And as a user, you want this to be obscure enough that people don't routinely publish bypasses, but well-used enough that it's properly maintained and reviewed.
Seems like it might be hard to thread that needle.
Patchguard isn't 100% about malware. In the XP-- days, antivirus/firewall vendors did all kinds of DKOM to install their hooks. This resulted in Windows being unstable in some cases, so with Vista Microsoft provided well defined hook points or highlighted existing ones like PsSetLoadImageNotifyRoutine (and deprecated the awful TDI stack for network inspection). The message at the time was "Dear AV people: use these defined hooks please" and Patchguard was basically "and we really mean it - DKOM is dead, stop doing it". It basically means you have a choice when distributing stable software: try to hack around with the kernel, risk bluescreening all your customers either because patchguard changed under you or you failed to correctly disable it etc, or you comply and use the blessed apis. Needless to say one is far less risky.
It also provides a bit of a speed bump for malware. To what extent this will do so for Linux is hard to say. There's plenty of public information on reverse engineering PatchGuard (https://github.com/tandasat/PgResarch, https://github.com/hfiref0x/UPGDSED for starters), and as you say this will likely come with public documentation of its inner workings.
I think this is interesting, but I think efforts like syzkaller and other "kernel hardening" efforts (to find correctness issues and fix bugs as fast as possible) are more valuable.
I think it would be interesting to have a processor that allowed you to specify a page mask of immutable pages once you cross a one-way privilege/ring threshold.
Does such a MMU/proc feature exist already? Seems like a feature like LKRG would be pretty effective in a case like that.
And if so the big remaining risk would be to the boot device chain security (which LKRG considers out of scope and for which several processors/SoCs already have covering security features).
So yes you could, but you'd have to know it was running in the first place.
The suggestion elsewhere to create an eBPF variant might be interesting to explore.