Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add BTF relocation support in eBPF programs #349

Open
v-thakkar opened this issue Jul 25, 2022 · 7 comments
Open

Add BTF relocation support in eBPF programs #349

v-thakkar opened this issue Jul 25, 2022 · 7 comments

Comments

@v-thakkar
Copy link

v-thakkar commented Jul 25, 2022

To be able to support BPF CO-RE, rustc needs to be able to generate the relocations of BTF types across different kernel versions. First part of this work requires adding core::intrinsics::{preserve_access_index, preserve_field_info, preserve_type_info, preserve_enum_value} for the BPF target in rustc. And then making sure/testing that the relocations work well with the userspace part of Aya.

@alessandrod
Copy link
Collaborator

Just to clarify: aya supports BTF relocations, see: https://github.com/aya-rs/aya/blob/main/aya/src/obj/btf/relocation.rs. So if you load an ebpf object file with BTF relocations, aya will be able to resolve them.

What doesn't support emitting BTF relocations yet is the rust compiler. So if you compile a rust program for the bpf*-unknown-none targets it will not emit BTF relocations.

@alessandrod alessandrod changed the title Add support for relocations in BTF types Add BTF relocation support to rustc Jul 25, 2022
@GermanCoding
Copy link

What would be needed to get the preserve_access_index, preserve_field_info, preserve_type_info, preserve_enum_value builtins into rustc? I guess some issue/PR over on https://github.com/rust-lang/rust? I would really like to see this feature in Rust, so as to have a really complete CORE solution pretty much equivalent to what you can do in C today. However I don't feel qualified enough to open an issue on the Rust project myself, so maybe someone here has more expertise with this?

@l2dy
Copy link
Contributor

l2dy commented Sep 7, 2024

First part of this work requires adding core::intrinsics::{preserve_access_index, preserve_field_info, preserve_type_info, preserve_enum_value} for the BPF target in rustc.

Is it possible to experiment with the new intrinsics with the link_llvm_intrinsics feature in unstable?

What would be needed to get the preserve_access_index, preserve_field_info, preserve_type_info, preserve_enum_value builtins into rustc? I guess some issue/PR over on https://github.com/rust-lang/rust?

Rust language feature requests should be discussed on the internals forum first, and then follow the RFC process if asked to. @GermanCoding If you are really interested in this feature, feel free to ask on the forum.

@v-thakkar
Copy link
Author

@l2dy @GermanCoding I think @vadorovsky had some discussions regarding this with the Rust community and there has been some WIP regarding the same. Maybe he can shed more light onto it.

@vadorovsky vadorovsky changed the title Add BTF relocation support to rustc Add BTF relocation support in eBPF programs Sep 11, 2024
@vadorovsky
Copy link
Member

vadorovsky commented Sep 11, 2024

I'm currently trying to achieve that without any changes in Rust compiler - I updated the issue title to generalize it.

Instead, I'm trying to emit these intrinsic calls in https://github.com/aya-rs/bpf-linker, which as a bitcode linker, is alreaady capable of modifying LLVM IR before producing the actual BPF binary.

Clang is producing the @llvm.preserve.array.access.index, @llvm.preserve.struct.access.index and @llvm.preserve.array.access.index intrinsics by performing regular calls of LLVM API, the code is here:

https://github.com/llvm/llvm-project/blob/cb6a62369a353f506a1dde087eeaf5ebea5d5c26/llvm/lib/IR/IRBuilder.cpp#L1260-L1285

The idea is to do the same in bpf-linker whenever we find a getelementptr instruction followed by load which is done on a type, for which we would like to emit BTF relocations.

Clang has two ways of enabling BTF relocations:

  • For the whole type, by annotating it with __attribute__((preserve_access_index)), e.g.
struct foo {
  int a;
  int b;
  int c;
  int d;
} __attribute__((preserve_access_index));

int get_a(struct foo *foo) {
  return foo->a;  // <-- this already does BTF relocations
}
  • For a single field, if it's being accessed with __builtin_preserve_access_index, e.g.
struct foo {
  int a;
  int b;
  int c;
  int d;
}

int get_a(struct foo *foo) {
  return __builtin_preserve_access_index(foo->a); // <- this does BTF relocation, but the
                                                  // intrinsics are emitted just for field `a`
}

How we could achieve equivalent way of notifying bpf-linker about necessity of emitting the intrinsic for the given type or field? We can use a custom PhantomData field which won't affect the layout of the type.

  • For the whole type, we could look for _btf_marker: PhantomData<()>, e.g.
#[repr(C)]
pub struct Foo {
    a: i32,
    b: i32,
    c: i32,
    d: i32,
    _btf_marker: PhantomData<()>,
}
  • For a single field, we could look for _btf_marker_FIELD_NAME: PhantomData<()>, e.g.
#[repr(C)]
pub struct Foo {
    a: i32,
    b: i32,
    c: i32,
    d: i32,
    _btf_marker_a: PhantomData<()>,
}

Of course the code examples above are ugly and we don't want users to write such code. We could hide them with macros and make the final code look like:

// This would emit BTF relocs for the whole type
#[repr(C)]
#[derive(Btf)]
pub struct 
    a: i32,
    b: i32,
    c: i32,
    d: i32,
}
// This would emit BTF relocs only for annotated fields
#[repr(C)]
#[derive(Btf)]
pub struct 
    a: i32,
    b: i32,
    c: i32,
    #[btf]
    d: i32,
}

To be more explicit, the plan going forward is:

@canoriz
Copy link

canoriz commented Sep 27, 2024

I'm new to aya. Does this mean an eBPF ELF object compiled from rust may not be CO-RE (because lack of index in ELF), and we are working on it now?

@vadorovsky
Copy link
Member

I'm new to aya. Does this mean an eBPF ELF object compiled from rust may not be CO-RE (because lack of index in ELF), and we are working on it now?

Sorry for late reply. Yes, that exactly the case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants