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
