google / buzzer Goto Github PK
View Code? Open in Web Editor NEWLicense: Apache License 2.0
License: Apache License 2.0
Currently in the codebase we do a lot of return fmt.Errorf(...)
which is convenient but makes making sure that an error is a certain type a lot harder and creates fragile conditions for testing where we rely a lot on error strings.
Ideally we should have a list of errors somewhere that we export to users that can then go ahead and use those errors for comparisons, assertions, etc.
Hi, I prepared the environment as the buzzer and syzkaller docs describe, and it goes smoothly.
but when I run buzzer in the vm, it gets "Fuzzer run no 0" as bellows:
root@syzkaller:~# ls
buzzer sourceFiles vmlinux
root@syzkaller:~# ./buzzer
running fuzzing strategy parse_verifier_log
Fuzzer run no 0.
Besides, I can only see "404 page not found" on the webpage http://localhost:8080/
.
Is the buzzer running? what should I have seen in this step?
I don't know what happens, could you please give me some advice?
Thanks.
Hi there!
I've had buzzer running for 16+ hours and my metrics server shows no coverage for verifier.c
I'm not sure if I'm not giving it the file parameter correctly. It would be good to know where I may need to troubleshoot
Currently working at creating wrappers around ebpf instructions to make the creation of ebpf programs friendlier. Once this work is landed, we would invoke a helper function (e.g map_lookup_element) like this:
Mov64(R1, ptr_to_map)
Mov64(R2, key)
CallFunction(map_lookup_element)
While doing this I noticed we could also create wrappers around ebpf helper functions, that would set up the registers in the right state, so the above example would turn into:
bpf_map_lookup_elemen(ptr_to_map, key)
Landing this work would be dependent on the refactoring that I am working on right now, so opening this issue for tracking purposes.
Consider submitting a pull request via https://github.com/ebpf-io/ebpf.io-website/pulls
syzkaller is a coverage-guided OS kernel fuzzer. It can generate BPF programs of low quality and could benefit from a high-quality BPF generator. It won't be as efficient as Buzzer in stressing BPF subsystem itself, but will uncover bugs in more complex interactions between BPF programs and other kernel subsystems.
I have a prototype for integration, which you can mostly ignore except for the proposed interface between syzkaller and Buzzer:
// This is supposed to be buzzer.Generate.
// progType is the program type (BPF_PROG_TYPE_SOCKET_FILTER/KPROBE/...).
// oldInsns is the program for mutation, if empty, generate a new one.
// Returns new/mutated program and number of used map fd's in bpf_attr::fd_array.
func BuzzerGenerate(progType int, rnd *rand.Rand, oldInsns []uint64) (insns []uint64, maps int)
Buzzer and syzkaller has some model mismatch as syzkaller generates and mutates programs offline. So it's not possible to embed actual map fd's into the program (they don't exist yet, and we are not even running on the target machine).
So I restricted it to use of only bpf_attr::fd_array, which syzkaller will fill with requested number of fd's later.
It is possible to use fd's embed in the program, but it will require some for of a-la ELF relocations (buzzer will need to say what offsets in the program should contain fd's and which of these refer to the same/different maps). I decided to left this out for now.
Any other ideas on how to design the interface? Anything I've missed? Do we need attach type here? Or map types? Or anything to make it possible to call C functions from the BPF program?
The current implementation cannot support the MovReg64 well.
In pkg/ebpf/alu_instructions.go
, although there is a function called MovRegImm64
, however, the arguments only supports the imm32.
// MovRegImm64 sets re to the specified value
func MovRegImm64(reg *Register, imm int32) *AluImmInstruction {
return NewAluImmInstruction(AluMov, InsClassAlu64, reg, imm)
}
For the following simple ebpf program
#define BPF_NO_GLOBAL_DATA
#include <linux/bpf.h>
#include <bpf/bpf_helpers.h>
#include <bpf/bpf_tracing.h>
typedef unsigned int u32;
typedef int pid_t;
const pid_t pid_filter = 0;
char LICENSE[] SEC("license") = "Dual BSD/GPL";
SEC("tp/syscalls/sys_enter_write")
int handle_tp(void *ctx)
{
pid_t pid = bpf_get_current_pid_tgid() >> 32;
if (pid_filter && pid != pid_filter)
return 0;
bpf_printk("BPF triggered sys_enter_write from PID %d.\n", pid);
return 0;
}
The disassembled result is:
Disassembly of section tp/syscalls/sys_enter_write:
0000000000000000 <handle_tp>:
0: 85 00 00 00 0e 00 00 00 call 0xe
1: b7 01 00 00 64 2e 0a 00 r1 = 0xa2e64
2: 63 1a f8 ff 00 00 00 00 *(u32 *)(r10 - 0x8) = r1
3: 18 01 00 00 6f 6d 20 50 00 00 00 00 49 44 20 25 r1 = 0x2520444950206d6f ll
5: 7b 1a f0 ff 00 00 00 00 *(u64 *)(r10 - 0x10) = r1
6: 18 01 00 00 77 72 69 74 00 00 00 00 65 20 66 72 r1 = 0x7266206574697277 ll
8: 7b 1a e8 ff 00 00 00 00 *(u64 *)(r10 - 0x18) = r1
9: 18 01 00 00 73 5f 65 6e 00 00 00 00 74 65 72 5f r1 = 0x5f7265746e655f73 ll
11: 7b 1a e0 ff 00 00 00 00 *(u64 *)(r10 - 0x20) = r1
12: 18 01 00 00 67 65 72 65 00 00 00 00 64 20 73 79 r1 = 0x7973206465726567 ll
14: 7b 1a d8 ff 00 00 00 00 *(u64 *)(r10 - 0x28) = r1
15: 18 01 00 00 42 50 46 20 00 00 00 00 74 72 69 67 r1 = 0x6769727420465042 ll
17: 7b 1a d0 ff 00 00 00 00 *(u64 *)(r10 - 0x30) = r1
18: 77 00 00 00 20 00 00 00 r0 >>= 0x20
19: bf a1 00 00 00 00 00 00 r1 = r10
20: 07 01 00 00 d0 ff ff ff r1 += -0x30
21: b7 02 00 00 2c 00 00 00 r2 = 0x2c
22: bf 03 00 00 00 00 00 00 r3 = r0
23: 85 00 00 00 06 00 00 00 call 0x6
24: b7 00 00 00 00 00 00 00 r0 = 0x0
25: 95 00 00 00 00 00 00 00 exit
There are instructions that load imm64 to the register, however in the code, it only supports imm64.
uname: 5.19.17
os-release:
root@syzkaller:~# cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
NAME="Debian GNU/Linux"
VERSION_ID="12"
VERSION="12 (bookworm)"
VERSION_CODENAME=bookworm
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"
qemu-system-x86_64 \
-m 8G \
-smp 4 -cpu host \
-kernel /home/g0dA/kernel/linux-5.19.17/arch/x86/boot/bzImage \
-append "console=ttyS0 root=/dev/sda earlyprintk=serial net.ifnames=0" \
-drive file=/home/g0dA/kernel/debian/debian.img,format=raw \
-net user,host=10.0.2.10,hostfwd=tcp:127.0.0.1:10021-:22,hostfwd=tcp:127.0.0.1:8888-:8080 \
-net nic,model=e1000 \
-enable-kvm \
-nographic \
-pidfile vm.pid
root@syzkaller:~# ls
buzzer sourceFiles vmlinux
root@syzkaller:~# ./buzzer
......
2023/05/03 02:09:54 failed to init control unit: Run program did not succee
and have output like this:
program flaked1974.
Writing verifier log to "/tmp/verifier-log-302911802".
Writing eBPF binary to "/tmp/ebpf-binary-3260864109".
"strconv.Atoi: parsing \"?\": invalid syntax"
Make complaints....Compiling is really cumbersome and requires gcc 12+
We have only implemented a few ebpf operation helper functions for the sake of prototyping in pr 26 (#26). We need to finish the implementation of these helper functions to consider the milestone completed
Hello, I'm curious to know how you configure the IDE while developing. Although I am able to run the project from the command line and fuzzing, I am having trouble reading the code and jumping to see the function definitions and references.
I don't know much about bazel, and I tried to set up the dev environment for several days. What's worse.. There is no tutorials about develop go program with bazel.
Hope to get a reply
This will allow external projects to import Buzzer's ebpf generation library
It is an excellent work. But I came accross some trouble when using Buzzer.
I successfully compiled and installed Buzzer according to the REAME.
However, it kept rasing error "Bad address" when executing eBPF prog.
My environment: OS 20.04, gcc-10
I configured Buzzer with the default settings and made sure that the BPF syscall is accessible as BCC worked fine.
Do you have any idea?
Traceback:
36 $ bazel build :buzzer
INFO: Analyzed target //:buzzer (12 packages loaded, 42 targets configured).
INFO: Found 1 target...
ERROR: /Users/piotrostr/buzzer/ebpf_ffi/BUILD:21:11: Compiling ebpf_ffi/ffi.cc failed: (Exit 1): cc_wrapper.sh failed: error executing command (from target //ebpf_ffi:ebpf_ffi) external/local_config_cc/cc_wrapper.sh -U_FORTIFY_SOURCE -fstack-protector -Wall -Wthread-safety -Wself-assign -Wunused-but-set-parameter -Wno-free-nonheap-object -fcolor-diagnostics ... (remaining 41 arguments skipped)
Use --sandbox_debug to see verbose messages from the sandbox and retain the sandbox build root for debugging
In file included from ebpf_ffi/ffi.cc:15:
./ebpf_ffi/ffi.h:22:10: fatal error: 'linux/bpf.h' file not found
#include <linux/bpf.h>
^~~~~~~~~~~~~
1 error generated.
Target //:buzzer failed to build
Use --verbose_failures to see the command lines of failed build steps.
INFO: Elapsed time: 2.488s, Critical Path: 0.97s
INFO: 14 processes: 8 internal, 6 darwin-sandbox.
FAILED: Build did NOT complete successfully
Environment:
Currently we only support programs attached to a Socket.
However the list of types of programs that ebpf supports is huge https://docs.kernel.org/bpf/libbpf/program_types.html and some of them might touch areas of the verifier that a network filter wouldn't.
I propose we extend the number of supported programs as much as we can.
Roughly we could refactor the FFI layer to introduce a type of executor per program type.
Hi,
I have been reviewing the PointerArithmetic
strategy in the buzzer
project and I have some questions regarding the logic used to determine if a boundary write has occurred. Specifically, I am confused about the comparison of the contents at key 0 and key 1 in the map to determine if a boundary write has occurred.
Code in Question:
// Footer part of the GenerateProgram method
footer, err := InstructionSequence(
// Select a random register and store its value in R8.
Mov64(R8, RandomRegister()),
// Load a fd to the map.
LdMapByFd(R9, pa.mapFd),
// Begin by writing a value to the map without ptr arithmetic.
StW(R10, 0, -4),
Mov64(R2, R10),
Add64(R2, -4),
Mov64(R1, R9),
Call(MapLookup),
JmpNE(R0, 0, 1),
Exit(),
StDW(R0, 0xCAFE, 0),
// Now repeat the operation but doing pointer arithmetic.
StW(R10, 1, -4),
Mov64(R2, R10),
Add64(R2, -4),
Mov64(R1, R9),
Call(MapLookup),
JmpNE(R0, 0, 1),
Exit(),
// Do math with the random register selected at the start.
Add64(R0, R8),
StDW(R0, 0xCAFE, 0),
// Exit
Mov64(R0, 0),
Exit(),
)
Issue:
The strategy compares the contents at key 0 and key 1 in the map to determine if a boundary write has occurred:
func (pa *PointerArithmetic) OnExecuteDone(ffi *units.FFI, executionResult *fpb.ExecutionResult) bool {
mapElements, err := ffi.GetMapElements(pa.mapFd, 2)
if err != nil {
fmt.Println(err)
return true
}
return mapElements.Elements[0] == mapElements.Elements[1]
}
However, if R8
is not zero, the pointer arithmetic will cause the value to be written to an offset location, which means the contents at key 0 and key 1 will inherently be different. This makes the comparison unreliable for detecting boundary writes.
Questions:
R8
?I appreciate any clarification or guidance you can provide on this matter.
Thank you!
Hi there!
I keep getting:
program xxxx flaked
does this indicate a crash ?
Hi!
I've had buzzer running for 10+ hours and my metrics server shows no information (i.e., 404 page not found).
I compiled my kernel with kcov
and kasan
as the syzkaller instructions, and built the bullseye
image,
and replace the PATH_TO_DEBIAN_IMAGE
and PATH_TO_KERNEL_REPO
with absolute path like /home/xxx/workspace/image/
and /home/xxx/workspace/kernel/
, and my kernel build .config
includes:
"CONFIG_BPF=y
CONFIG_BPF_SYSCALL=y
CONFIG_KCOV=y
CONFIG_KASAN=y"
I'm not sure where the problem is. It might be similar to issue/37, but I haven't understood the solution. Please provide some assistance. Thank you.
Hi, I ran buzzer with 20G RAM and OOM-killer problem occurred as mentioned in #58. When I increased the RAM to 40G, the problem still exists as below. I think there might be a memory leak in buzzer. Could you help me with this?
In addition, I used the -strategy=pointer_arithmetic
which is tagged deprecated, and I didn't find any bugs. May I know which -strategy
is more likely to find bugs?
from 262 to 264: R0=map_value(ks=4,vs=8) R6=scalar() R7=0xffffffff80000000 R8=0x372b167a R9=map_ptr(ks=4,vs=8) R10=fp0 fp-8=mmmm????
264: R0=map_value(ks=4,vs=8) R6=scalar() R7=0xffffffff80000000 R8=0x372b167a R9=map_ptr(ks=4,vs=8) R10=fp0 fp-8=mmmm????
264: (0f) r0 += r8
mark_precise: frame0: last_idx 264 first_idx 262 subseq_idx -1
mark_precise: frame0: regs=r8 stack= before 262: (55) if r0 != 0x0 goto pc+1
mark_precise: frame0: parent state regs=r8 stack=: R0_rw=map_value_or_null(id=2,ks=4,vs=8) R6=scalar() R7=0xffffffff80000000 R8_r=P0x372b167a R9=map_ptr(ks=4,vs=8) R10=fp0 f?
mark_precise: frame0: last_idx 261 first_idx 254 subseq_idx 262
mark_precise: frame0: regs=r8 stack= before 261: (85) call bpf_map_lookup_elem#1
mark_precise: frame0: regs=r8 stack= before 260: (bf) r1 = r9
mark_precise: frame0: regs=r8 stack= before 259: (07) r2 += -4
mark_precise: frame0: regs=r8 stack= before 258: (bf) r2 = r10
mark_precise: frame0: regs=r8 stack= before 257: (62) *(u32 *)(r10 -4) = 1
mark_precise: frame0: regs=r8 stack= before 256: (7a) *(u64 *)(r0 +0) = 51966
mark_precise: frame0: regs=r8 stack= before 254: (55) if r0 != 0x0 goto pc+1
mark_precise: frame0: parent state regs=r8 stack=: R0_rw=map_value_or_null(id=1,ks=4,vs=8) R6_w=scalar() R7=0xffffffff80000000 R8_rw=P0x372b167a R9_rw=map_ptr(ks=4,vs=8) R10?
mark_precise: frame0: last_idx 253 first_idx 237 subseq_idx 254
mark_precise: frame0: regs=r8 stack= before 253: (85) call bpf_map_lookup_elem#1
mark_precise: frame0: regs=r8 stack= before 252: (bf) r1 = r9
mark_precise: frame0: regs=r8 stack= before 251: (07) r2 += -4
mark_precise: frame0: regs=r8 stack= before 250: (bf) r2 = r10
mark_precise: frame0: regs=r8 stack= before 249: (62) *(u32 *)(r10 -4) = 0
mark_precise: frame0: regs=r8 stack= before 247: (18) r9 = 0xffff888119f4fc00
mark_precise: frame0: regs=r8 stack= before 246: (bf) r8 = r1
mark_precise: frame0: regs=r1 stack= before 245: (37) r6 /= -1198429702
mark_precise: frame0: regs=r1 stack= before 244: (87) r2 = -r2
mark_precise: frame0: regs=r1 stack= before 243: (4c) w6 |= w1
mark_precise: frame0: regs=r1 stack= before 242: (47) r9 |= -1347492013
mark_precise: frame0: regs=r1 stack= before 241: (54) w5 &= 1831304382
mark_precise: frame0: regs=r1 stack= before 240: (af) r9 ^= r0
mark_precise: frame0: regs=r1 stack= before 239: (1d) if r7 == r1 goto pc+5
mark_precise: frame0: regs=r1,r7 stack= before 238: (b7) r3 = -73889241
mark_precise: frame0: regs=r1,r7 stack= before 237: (1c) w9 -= w3
mark_precise: frame0: parent state regs= stack=: R0_r=0xffffffffc4ff83eb R1_rw=P0x372b167a R2_r=1 R3_r=0xffffffff9f1e1499 R4_w=scalar(smin=0,smax=umax=0xffffffff,var_off=(0x0
math between map_value pointer and 925570682 is not allowed
processed 47 insns (limit 1000000) max_states_per_insn 0 total_states 4 peak_states 4 mark_read 2
[155991.590243] buzzer invoked oom-killer: gfp_mask=0x2dc2(GFP_KERNEL|__GFP_HIGHMEM|__GFP_NOWARN|__GFP_ZERO), order=0, oom_score_adj=0
[155991.590687] CPU: 0 PID: 219 Comm: buzzer Not tainted 6.10.0-rc1-00027-g4a4be1ad3a6e #2
[155991.590924] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
[155991.591172] Call Trace:
[155991.591260] <TASK>
[155991.591331] dump_stack_lvl+0xab/0xe0
[155991.591455] dump_header+0x102/0xc20
[155991.591573] ? _raw_spin_lock+0x80/0xe0
[155991.591695] ? ___ratelimit+0x99/0x460
[155991.591817] oom_kill_process+0x846/0xe20
[155991.591946] ? task_will_free_mem+0xac/0x650
[155991.592082] ? oom_badness+0x522/0x670
[155991.592204] out_of_memory+0x2cb/0x1af0
[155991.592328] ? __pfx_out_of_memory+0x10/0x10
[155991.592464] ? __pfx_mutex_trylock+0x10/0x10
[155991.592600] ? zone_reclaimable_pages+0x74f/0x8e0
[155991.592749] __alloc_pages_noprof+0x1884/0x1ec0
[155991.592894] ? update_load_avg+0x124/0x1fd0
[155991.593028] ? sysvec_call_function_single+0x18/0xc0
[155991.593182] ? __pfx___alloc_pages_noprof+0x10/0x10
[155991.593335] ? sysvec_call_function_single+0x18/0xc0
[155991.593489] ? sysvec_call_function_single+0x18/0xc0
[155991.593643] ? sysvec_apic_timer_interrupt+0xf/0x80
[155991.593795] ? __sanitizer_cov_trace_switch+0x54/0x90
[155991.593954] ? policy_nodemask+0xeb/0x4b0
[155991.594083] alloc_pages_mpol_noprof+0xf2/0x330
[155991.594228] ? __pfx_alloc_pages_mpol_noprof+0x10/0x10
[155991.594389] ? alloc_pages_noprof+0x139/0x150
[155991.594529] ? __sanitizer_cov_trace_pc+0x17/0x60
[155991.594678] __vmalloc_node_range_noprof+0xa87/0x1310
[155991.594838] ? kcov_ioctl+0x4f/0x6a0
[155991.594955] ? __pfx___vmalloc_node_range_noprof+0x10/0x10
[155991.595125] ? __pfx_do_sys_openat2+0x10/0x10
[155991.595267] ? kcov_ioctl+0x4f/0x6a0
[155991.595383] vmalloc_user_noprof+0x9e/0xe0
[155991.595514] ? kcov_ioctl+0x4f/0x6a0
[155991.595629] kcov_ioctl+0x4f/0x6a0
[155991.595741] ? __pfx_kcov_ioctl+0x10/0x10
[155991.595871] __x64_sys_ioctl+0x1a1/0x210
[155991.596003] do_syscall_64+0xa6/0x1a0
[155991.596121] entry_SYSCALL_64_after_hwframe+0x77/0x7f
[155991.596279] RIP: 0033:0xaddb7f
[155991.596399] Code: Unable to access opcode bytes at 0xaddb55.
[155991.596570] RSP: 002b:00007fadae1cdde0 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
[155991.596796] RAX: ffffffffffffffda RBX: 000000c000052d08 RCX: 0000000000addb7f
[155991.597009] RDX: 0000000004000000 RSI: 0000000080086301 RDI: 0000000000000007
[155991.597222] RBP: 00007fadae1cde60 R08: 0000000000000000 R09: 0000000000000000
[155991.597434] R10: 0000000000000000 R11: 0000000000000246 R12: ffffffffffffffff
[155991.597647] R13: 0000000000000008 R14: 000000c0000061a0 R15: 0000000000000020
[155991.597860] </TASK>
[155991.597941] Mem-Info:
[155991.598016] active_anon:27 inactive_anon:8402365 isolated_anon:0
[155991.598016] active_file:0 inactive_file:2 isolated_file:0
[155991.598016] unevictable:0 dirty:0 writeback:0
[155991.598016] slab_reclaimable:9131 slab_unreclaimable:296105
[155991.598016] mapped:6483 shmem:10296 pagetables:16815
[155991.598016] sec_pagetables:0 bounce:0
[155991.598016] kernel_misc_reclaimable:0
[155991.598016] free:47811 free_pcp:29085 free_cma:0
[155991.599280] Node 0 active_anon:108kB inactive_anon:33609460kB active_file:0kB inactive_file:156kB unevictable:0kB isolated(anon):0kB isolated(file):0kB mapped:25932kB dirs
[155991.600386] Node 0 DMA free:14968kB boost:0kB min:8kB low:20kB high:32kB reserved_highatomic:0KB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB uneviB
[155991.601526] lowmem_reserve[]: 0 2891 34893 0
[155991.601809] Node 0 DMA32 free:129084kB boost:0kB min:1980kB low:4940kB high:7900kB reserved_highatomic:0KB active_anon:0kB inactive_anon:2780836kB active_file:56kB inactiB
[155991.603028] lowmem_reserve[]: 0 0 32001 0
[155991.603202] Node 0 Normal free:47192kB boost:61440kB min:83360kB low:116128kB high:148896kB reserved_highatomic:0KB active_anon:108kB inactive_anon:30828624kB active_fileB
[155991.604266] lowmem_reserve[]: 0 0 0 0
[155991.604403] Node 0 DMA: 2*4kB (M) 1*8kB (M) 1*16kB (M) 3*32kB (M) 0*64kB 4*128kB (M) 4*256kB (M) 4*512kB (M) 5*1024kB (UM) 3*2048kB (M) 0*4096kB = 14976kB
[155991.604962] Node 0 DMA32: 889*4kB (M) 279*8kB (UM) 154*16kB (UM) 121*32kB (M) 56*64kB (M) 72*128kB (M) 55*256kB (UM) 51*512kB (M) 40*1024kB (UM) 11*2048kB (UM) 0*4096kB =B
[155991.605531] Node 0 Normal: 824*4kB (ME) 1028*8kB (UME) 669*16kB (UME) 552*32kB (UME) 113*64kB (UM) 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 47120kB
[155991.606047] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB
[155991.606371] 10602 total pagecache pages
[155991.606501] 0 pages in swap cache
[155991.606664] Free swap = 0kB
[155991.606759] Total swap = 0kB
[155991.606914] 10485630 pages RAM
[155991.607017] 0 pages HighMem/MovableOnly
[155991.607192] 1546389 pages reserved
[155991.607302] Tasks state (memory values in pages):
[155991.607506] [ pid ] uid tgid total_vm rss rss_anon rss_file rss_shmem pgtables_bytes swapents oom_score_adj name
[155991.607904] [ 87] 0 87 21301 11108 192 131 10785 212992 0 -250 systemd-journal
[155991.608311] [ 102] 0 102 8952 2570 2570 0 0 102400 0 -1000 systemd-udevd
[155991.608712] [ 127] 0 127 1409 105 64 41 0 57344 0 0 cron
[155991.609098] [ 146] 0 146 55233 476 340 136 0 77824 0 0 rsyslogd
[155991.609490] [ 167] 0 167 24971 344 311 33 0 77824 0 0 dhclient
[155991.609885] [ 193] 0 193 3338 274 224 50 0 65536 0 -1000 sshd
[155991.610267] [ 194] 0 194 718 78 32 46 0 49152 0 0 agetty
[155991.610674] [ 195] 0 195 718 39 0 39 0 45056 0 0 agetty
[155991.611090] [ 196] 0 196 718 58 32 26 0 40960 0 0 agetty
[155991.611489] [ 197] 0 197 718 64 32 32 0 45056 0 0 agetty
[155991.611890] [ 198] 0 198 718 46 0 46 0 40960 0 0 agetty
[155991.612285] [ 199] 0 199 718 33 0 33 0 53248 0 0 agetty
[155991.612683] [ 200] 0 200 2085 143 128 15 0 57344 0 0 login
[155991.613075] [ 207] 0 207 1513 147 96 51 0 57344 0 0 bash
[155991.613462] [ 216] 0 216 8669850 8385063 8385006 57 0 67465216 0 0 buzzer
[155991.613861] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,task=buzzer,pid=216,uid=0
[155991.614184] Out of memory: Killed process 216 (buzzer) total-vm:34679400kB, anon-rss:33540024kB, file-rss:228kB, shmem-rss:0kB, UID:0 pgtables:65884kB oom_score_adj:0
[155991.614868] buzzer (221) used greatest stack depth: 23896 bytes left
[155995.732880] oom_reaper: reaped process 216 (buzzer), now anon-rss:16kB, file-rss:228kB, shmem-rss:0kB
If I want to test a specific type of ebpf, such as socket-related or map-related, how should I do it?
While manually testing the fuzzer I noticed that bit shift operations generate a lot of invalid programs due to an invalid shift amount (e.g negativa values or values over 32/64).
The solution is simple: whenever we generate a bit shift operation, make sure the shift amount is always between [1, 31] or [1,63] depending on the instruction class.
Currently, this pattern gets repeated often to write an ebpf program:
var root, ptr, next ebpf.EBPFOperation
root := ALUIMMOperation(...)
ptr = root
next := ...
ptr.SetNextInstruction(next)
ptr = next
...
Ideally, programs should be built in a more readable and easier to write way, for example:
newEBPFSequence(
MOV64(R0, 0),
MOV64(R1, R0),
MUL64(R1, 10),
...
)
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.