netdev - Re: [PATCH bpf-next 0/4] libbpf: Move CO-RE logic into separate file.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAADnVQL3CSp9NASM-HLEKEuodEfKHjtU7mWDsrhJUCVy3R+V0g@mail.gmail.com>
Date:   Fri, 23 Jul 2021 17:23:32 -0700
From:   Alexei Starovoitov <alexei.starovoitov@...il.com>
To:     Toke Høiland-Jørgensen <toke@...hat.com>
Cc:     "David S. Miller" <davem@...emloft.net>,
        Daniel Borkmann <daniel@...earbox.net>,
        Andrii Nakryiko <andrii@...nel.org>,
        Network Development <netdev@...r.kernel.org>,
        bpf <bpf@...r.kernel.org>, Kernel Team <kernel-team@...com>
Subject: Re: [PATCH bpf-next 0/4] libbpf: Move CO-RE logic into separate file.

On Thu, Jul 22, 2021 at 9:02 AM Toke Høiland-Jørgensen <toke@...hat.com> wrote:
>
> Alexei Starovoitov <alexei.starovoitov@...il.com> writes:
>
> > From: Alexei Starovoitov <ast@...nel.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.