On Thu, Jul 22, 2021 at 9:02 AM Toke Høiland-Jørgensen [off-list ref] wrote:

Alexei Starovoitov [off-list ref] writes:

quoted

From: Alexei Starovoitov <ast@kernel.org>

Split CO-RE processing logic from libbpf into separate file
with an interface that doesn't dependend on libbpf internal details.
As the next step relo_core.c will be compiled with libbpf and with the kernel.

Interesting! What's the use case for having it in the kernel as well? :)

The main motivation is signed programs, of course.
Also there are other reasons:
- give the verifier precise path to the field in load/store instructions.
Currently it has to guess the field based on integer offset.
That guessing is random in case of a union.
- give the kermel ability to do CO-RE or symbolic field access.
The insn patching is a small part of the bpf_core_apply_relo_insn().
It can be done for x86 and any other archs just as well.
Imagine a true kernel struct randomization.
Not the existing one where gcc plugin does it at build time,
but the one where the kernel randomizes struct cred every single boot.
Or imagine kernel modules that are built once and then can be loaded
and run on a variety of kernels.