Support read /sys/bus/event_source/devices/uprobe/type on old kernel versions #248

zhangzihengya · 2024-03-09T08:29:19Z

solve #239

Officeyutong · 2024-03-09T10:21:23Z

/sys/bus/event_source/devices/uprobe/type was also accessed by libbpf, do you have any method to solve this?

zhangzihengya · 2024-03-09T10:34:57Z

/sys/bus/event_source/devices/uprobe/type was also accessed by libbpf, do you have any method to solve this?

Yes,Since we can't modify libbpf directly, what I modify is the contents of runtime/syscall-server library. ld_preload can override the open function in libc to achieve the effect of modification at runtime, so as to solve this problem.

Officeyutong · 2024-03-09T10:46:16Z

runtime/syscall-server/syscall_server_utils.cpp

+
+                return expanded_path;
+            } else {
+                fprintf(stderr, "Failed to allocate memory\n");


Please use spdlog to print logs

Officeyutong · 2024-03-09T10:47:43Z

runtime/syscall-server/syscall_server_utils.cpp

+        if (home_dir != NULL) {
+            // Allocate memory for the expanded path
+            size_t len = strlen(home_dir) + strlen(path) - 1;  // -1 to exclude ~
+            char *expanded_path = (char *)malloc(len + 1);     // +1 for the null terminator


Is the buffer allocated here leaked?

Officeyutong · 2024-03-09T10:48:33Z

/sys/bus/event_source/devices/uprobe/type was also accessed by libbpf, do you have any method to solve this?

Yes,Since we can't modify libbpf directly, what I modify is the contents of runtime/syscall-server library. ld_preload can override the open function in libc to achieve the effect of modification at runtime, so as to solve this problem.

I didn't see where you override the open function, will it be done in this PR?

Officeyutong · 2024-03-11T08:31:16Z

runtime/src/bpftime_shm.cpp

+{
+	const char *home_dir = getenv("HOME");
+	if (home_dir == NULL) {
+		SPDLOG_INFO("Error: HOME environment variable is not set");


Should it be SPDLOG_ERROR?

Officeyutong · 2024-03-11T08:32:36Z

runtime/syscall-server/syscall_context.hpp

@@ -23,13 +23,17 @@ class syscall_context {
 	using epoll_ctl_fn = int (*)(int, int, int, struct epoll_event *);
 	using epoll_wait_fn = int (*)(int, struct epoll_event *, int, int);
 	using munmap_fn = int (*)(void *, size_t);
+	using fopen_fn = FILE *(*)(const char *,const char *);
+	using open_fn = int (*)(const char *, int, ...);


Do we really need to override fopen? Doesn't fopen internally call open to open files?

In fact, the internal call of fopen is the openat system call, but when the program calls fopen, it does not trigger some of the processing done by bpftime to openat.

I did my tests on openat and didn't see that calling fopen would trigger some of the processing bpftime does for openat:

Set a breakpoint for handle_openat() as follows:

int syscall_context::handle_openat(int fd, const char *file, int oflag, unsigned short mode) { if (!enable_mock){ printf("1:%s\n",file); return orig_openat_fn(fd, file, oflag, mode); } try_startup(); printf("2:%s\n",file); const char * new_file = bpftime_checkfile(file); printf("3:%s\n",new_file); return orig_openat_fn(fd, new_file, oflag, mode); }

Test procedure:

... const char *filename = "/sys/bus/event_source/devices/uprobe/type"; FILE *file = fopen(filename, "r"); ...

Tracing the program using strace found that fopen calls the openat system call:

... openat(AT_FDCWD, "/sys/bus/event_source/devices/uprobe/type", O_RDONLY) = 3 ...

Executing the commandLD_PRELOAD=build/runtime/syscall-server/libbpftime-syscall-server.so./testproduces the following output without firing the breakpoint:

[2024-03-12 10:00:50.742] [info] [syscall_context.hpp:93] manager constructed Content: 9

Now change the test program to one that uses the openat function directly:

... const char *directory = "/sys/bus/event_source/devices"; const char *filename = "uprobe/type"; int dir_fd = open(directory, O_RDONLY); ... int file_fd = openat(dir_fd, filename, O_RDONLY); ...

Executing the command LD_PRELOAD=build/runtime/syscall-server/libbpftime-syscall-server.so./test produces the following output, and you can see that the breakpoint is triggered:

[2024-03-12 10:03:29.609] [info] [syscall_context.hpp:93] manager constructed [2024-03-12 10:03:29.609] [info] [syscall_server_utils.cpp:24] Initialize syscall server [2024-03-12 10:03:29][info][26465] Global shm constructed. shm_open_type 0 for bpftime_maps_shm [2024-03-12 10:03:29][info][26465] Enabling helper groups ufunc, kernel, shm_map by default [2024-03-12 10:03:29][info][26465] bpftime-syscall-server started 2:uprobe/type 3:uprobe/type Content: 9 INFO [26465]: Global shm destructed

Does bpftime only attach dynamic libraries to the surface of the program?

Another problem is that although this modified libbpf file access, but libbpf is actually want to get/sys/bus/event_source/devices/uprobe/type of value, and for low version of the kernel, the value is not exist, When libbpf gets the wrong value, it will also report an error (libbpf: prog 'do_count': failed to create uprobe '/lib/x86_64-linux-gnu/libc.so.6:0x9f920' perf event: Operation not permitted), when I changed the contents of the replacement file to the correct value, but the correct value does not exist for the lower kernel version, this method does not seem feasible.

I did my tests on openat and didn't see that calling fopen would trigger some of the processing bpftime does for openat:

Set a breakpoint for handle_openat() as follows:

int syscall_context::handle_openat(int fd, const char *file, int oflag, unsigned short mode) { if (!enable_mock){ printf("1:%s\n",file); return orig_openat_fn(fd, file, oflag, mode); } try_startup(); printf("2:%s\n",file); const char * new_file = bpftime_checkfile(file); printf("3:%s\n",new_file); return orig_openat_fn(fd, new_file, oflag, mode); }

Test procedure:

... const char *filename = "/sys/bus/event_source/devices/uprobe/type"; FILE *file = fopen(filename, "r"); ...

Tracing the program using strace found that fopen calls the openat system call:

... openat(AT_FDCWD, "/sys/bus/event_source/devices/uprobe/type", O_RDONLY) = 3 ...

Executing the commandLD_PRELOAD=build/runtime/syscall-server/libbpftime-syscall-server.so./testproduces the following output without firing the breakpoint:

[2024-03-12 10:00:50.742] [info] [syscall_context.hpp:93] manager constructed Content: 9

Now change the test program to one that uses the openat function directly:

... const char *directory = "/sys/bus/event_source/devices"; const char *filename = "uprobe/type"; int dir_fd = open(directory, O_RDONLY); ... int file_fd = openat(dir_fd, filename, O_RDONLY); ...

Executing the command LD_PRELOAD=build/runtime/syscall-server/libbpftime-syscall-server.so./test produces the following output, and you can see that the breakpoint is triggered:

[2024-03-12 10:03:29.609] [info] [syscall_context.hpp:93] manager constructed [2024-03-12 10:03:29.609] [info] [syscall_server_utils.cpp:24] Initialize syscall server [2024-03-12 10:03:29][info][26465] Global shm constructed. shm_open_type 0 for bpftime_maps_shm [2024-03-12 10:03:29][info][26465] Enabling helper groups ufunc, kernel, shm_map by default [2024-03-12 10:03:29][info][26465] bpftime-syscall-server started 2:uprobe/type 3:uprobe/type Content: 9 INFO [26465]: Global shm destructed

Does bpftime only attach dynamic libraries to the surface of the program?

Another problem is that although this modified libbpf file access, but libbpf is actually want to get/sys/bus/event_source/devices/uprobe/type of value, and for low version of the kernel, the value is not exist, When libbpf gets the wrong value, it will also report an error (libbpf: prog 'do_count': failed to create uprobe '/lib/x86_64-linux-gnu/libc.so.6:0x9f920' perf event: Operation not permitted), when I changed the contents of the replacement file to the correct value, but the correct value does not exist for the lower kernel version, this method does not seem feasible.

LD_PRELOAD can only replace functions that were dynamically linked, you may see man ld.so for details.

My hints for replacing statically linked functions: Use a linker script to manually override the linked function to a custom one. Is this practical?

Officeyutong · 2024-04-06T10:03:56Z

@zhangzihengya Hi, how's going on now?

Officeyutong · 2024-08-15T10:33:16Z

The following logic should be implemented in syscall-server (not in runtime):

Hook open and openat, create a fake fd (using open for an temporary file) and return it for access to /sys/bus/event_source/devices/uprobe/type
Hook read, for reading request to hooked files, writting the corresponding buffer

Officeyutong · 2024-08-16T08:41:12Z

I don't have permission to push into zhangzihengya:master, so I will open a new PR

Officeyutong · 2024-08-16T08:42:51Z

Replaced by #333

zhangzihengya added 3 commits March 7, 2024 18:33

perfect Dockerfile

7a98256

md Dockerfile

c8fd404

Supports kernel versions that do not support uprobe

830b869

pull-request-size bot added the size/M label Mar 9, 2024

zhangzihengya closed this Mar 9, 2024

zhangzihengya reopened this Mar 9, 2024

Officeyutong requested changes Mar 9, 2024

View reviewed changes

Officeyutong reviewed Mar 9, 2024

View reviewed changes

zhangzihengya added 3 commits March 10, 2024 17:56

override fopen

c4382d5

md syscall_server_main.cpp

2dc8538

md open

6809e48

Officeyutong reviewed Mar 11, 2024

View reviewed changes

test

3ab9c1d

pull-request-size bot added size/L and removed size/M labels Apr 2, 2024

Merge branch 'master' into master

4b23a68

Officeyutong self-assigned this Aug 15, 2024

Officeyutong mentioned this pull request Aug 16, 2024

[Replaces 248] Support read /sys/bus/event_source/devices/uprobe/type on old kernel versions #333

Merged

Officeyutong closed this Aug 16, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Support read /sys/bus/event_source/devices/uprobe/type on old kernel versions #248

Support read /sys/bus/event_source/devices/uprobe/type on old kernel versions #248

zhangzihengya commented Mar 9, 2024 •

edited

Loading

Officeyutong commented Mar 9, 2024 •

edited

Loading

zhangzihengya commented Mar 9, 2024 •

edited

Loading

Officeyutong Mar 9, 2024

Officeyutong Mar 9, 2024

Officeyutong commented Mar 9, 2024

Officeyutong Mar 11, 2024

Officeyutong Mar 11, 2024

zhangzihengya Mar 11, 2024

zhangzihengya Mar 12, 2024

Officeyutong Mar 12, 2024

Officeyutong commented Apr 6, 2024

Officeyutong commented Aug 15, 2024

Officeyutong commented Aug 16, 2024

Officeyutong commented Aug 16, 2024

Support read /sys/bus/event_source/devices/uprobe/type on old kernel versions #248

Support read /sys/bus/event_source/devices/uprobe/type on old kernel versions #248

Conversation

zhangzihengya commented Mar 9, 2024 • edited Loading

Officeyutong commented Mar 9, 2024 • edited Loading

zhangzihengya commented Mar 9, 2024 • edited Loading

Officeyutong Mar 9, 2024

Choose a reason for hiding this comment

Officeyutong Mar 9, 2024

Choose a reason for hiding this comment

Officeyutong commented Mar 9, 2024

Officeyutong Mar 11, 2024

Choose a reason for hiding this comment

Officeyutong Mar 11, 2024

Choose a reason for hiding this comment

zhangzihengya Mar 11, 2024

Choose a reason for hiding this comment

zhangzihengya Mar 12, 2024

Choose a reason for hiding this comment

Officeyutong Mar 12, 2024

Choose a reason for hiding this comment

Officeyutong commented Apr 6, 2024

Officeyutong commented Aug 15, 2024

Officeyutong commented Aug 16, 2024

Officeyutong commented Aug 16, 2024

zhangzihengya commented Mar 9, 2024 •

edited

Loading

Officeyutong commented Mar 9, 2024 •

edited

Loading

zhangzihengya commented Mar 9, 2024 •

edited

Loading