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

[Michal Hocko <mhocko@suse.com>]

On Mon 11-05-26 12:45:36, Sasha Levin wrote:
> Could you describe an existing infrastructure I can use here?

I think it would help to CC maintainers of subsystems that provide
kernel modification functionality. They will surely have a better
insight than me.

> Let's look at
> this recent "Copy Fail" thing as an example.
> 
> I can obviously build my own kernel and enroll my own key, but 99.9% of our
> users won't be doing that.
> Livepatching, or manually building a module that just injects a kprobe is out
> of the question as we previously agreed.

Onless I am mistaken you can enroll your own key through MOK. But you
are right that this is an additional step. But the real question is
whether this is a major road block for users of this specific feature.

> systemtap falls into the same bucket as building my own module.
> 
> BPF doesn't help because bpf_override_return() requires the target to be on the
> same within_error_injection_list() whitelist as fault injection, and the CVE
> targets never are. Some of our fleet doesn't even have BPF enabled either, but
> that's the smaller objection.
> 
> I can't use fault injection because:
> 
>  a. It's almost never built in production/distro kernels, and I suspect this
> won't change.
>  b. The functions I need are not whitelisted.
>  c. Even if (a) and (b) were addressed, fault injection would still need a
> securityfs front-end, a cmdline parser, a module-unload notifier, a taint flag,
> and audit on engage and disengage. By the time those land in fail_function and
> tie into/refactor the fault injection code, the net diff is bigger than this
> proposal.

I cannot comment on fault injection imeplementation details of course
but I have to say that the whitelist nature is something that makes its
use very limited. Maybe this is a good opportunity to change the
approach.

> 
> In my case I can remove the module, but not if I run a distro that shipped with
> CONFIG_CRYPTO_USER_API_AEAD=y (like RHEL/SUSE).

If you look at copy fail[2], IIRC algif_aead, esp[46] and rxrcp are all
modules that could be blacklisted.

> I can use "initcall_blacklist=" hack and reboot, but as things stand today,
> I'll need to be rebooting few times a day.

with your just disable some functions in the kernel you might need to
reboot even more. But more seriously...

> Even if I'm okay with rebooting that often (and I really really would prefer
> not to), this doesn't solve the issues of a larger fleet of servers that can't
> just reboot that often.
> 
> What am I missing?

For one, you are missing more maintainers of code modification infrastructures. 
-- 
Michal Hocko
SUSE Labs