Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

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

bpf2go: type *btf.Pointer: not supported #1064

Closed
cleverhu opened this issue Jun 14, 2023 · 1 comment
Closed

bpf2go: type *btf.Pointer: not supported #1064

cleverhu opened this issue Jun 14, 2023 · 1 comment
Labels
bug Something isn't working

Comments

@cleverhu
Copy link

cleverhu commented Jun 14, 2023

Describe the bug
The inability to directly read the filename in sys_enter_openat is due to the fact that upon entering the system call, the filename (a user space pointer) may not have been fully resolved and filled into memory yet, so it cannot be correctly read via bpf_probe_read_user(). Therefore, I wrote the following code. However, when running the script generation command, an error occurred. How should I handle this to solve the problem?
To Reproduce
Steps to reproduce the behavior. Please include:

file openat.bpf.c

//go:build ignore
#include <vmlinux.h>
#include <bpf/bpf_helpers.h>

struct {
	__uint(type, BPF_MAP_TYPE_HASH);
	__uint(max_entries, 10240);
	__type(key, u32);
	__type(value, struct openat_args);
} start SEC(".maps");
#define NAME_MAX 255

struct openat_args {
    int flags;
    const char *fname_ptr;
    char fname[NAME_MAX];
};

SEC("tp/syscalls/sys_enter_openat")
int enter_openat(struct trace_event_raw_sys_enter* ctx)
{
   	u64 id = bpf_get_current_pid_tgid();
    struct openat_args arg ={};
    arg.flags = (int)ctx->args[2];
    arg.fname_ptr = (const char *)ctx->args[1];

    bpf_map_update_elem(&start, &id, &arg, BPF_ANY);
    return 0;
}

SEC("tp/syscalls/sys_exit_openat")
int exit_openat(struct trace_event_raw_sys_exit* ctx)
{
   	u64 id = bpf_get_current_pid_tgid();
    struct openat_args *arg = bpf_map_lookup_elem(&start, &id);
    if (!arg) {
        return 0;
    }

    // Read filename on syscall exit
    bpf_probe_read_user(&arg->fname, sizeof(arg->fname), (void *)arg->fname_ptr);

    bpf_printk("openat: filename: %s flags: %d\n",arg->fname,arg->flags);
    bpf_map_delete_elem(&start, &id);
    return 0;
}

char LICENSE[] SEC("license") = "GPL";

doc.go

package openat

// $BPF_CLANG and $BPF_CFLAGS are set by the Makefile.
//go:generate bpf2go -cc $BPF_CLANG -cflags $BPF_CFLAGS bpf openat.bpf.c -- -I../headers

error

Compiled /root/go/src/tp-test/ebpf/openat/bpf_bpfel.o
Stripped /root/go/src/tp-test/ebpf/openat/bpf_bpfel.o
Error: can't write /root/go/src/tp-test/ebpf/openat/bpf_bpfel.go: can't generate types: template: common:19:4: executing "common" at <$.TypeDeclaration>: error calling TypeDeclaration: Struct:"openat_args": field 1: type *btf.Pointer: not supported

Expected behavior
run go generate should be succeed

@cleverhu cleverhu added the bug Something isn't working label Jun 14, 2023
@lmb
Copy link
Collaborator

lmb commented Jun 15, 2023

struct openat_args {
    int flags;
    const char *fname_ptr;
    char fname[NAME_MAX];
};

The problem here is fname_ptr as you've probably figured out. Pointers are not supported because we can't put C pointer values into Go pointer types. Taking a pointer from kernel space and doing something with it in user space in general is complicated. The way to work around this is by changing the type declaration:

struct openat_args {
    int flags;
    uintptr_t fname_ptr;
    char fname[NAME_MAX];
};

Instead of a pointer you store the raw value of the pointer. In userspace you can retrieve that value and do with it what you want (maybe via ptrace?), but you can't stuff it into a Go pointer.

@lmb lmb changed the title type *btf.Pointer: not supported bpf2go: type *btf.Pointer: not supported Jun 15, 2023
@cilium cilium locked and limited conversation to collaborators Jun 15, 2023
@lmb lmb converted this issue into discussion #1066 Jun 15, 2023

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants