Closed Clingto closed 5 months ago
The host machine is ubuntu 22.04, and the VM is the latest linux kernel.
Hi!
i think you might have an outdated version of the repo. Could you git pull
and try again?
Thank you for your reply! I git pull the latest repo with the command "git clone --recursive https://github.com/google/buzzer.git". And then, I run buzzer with the command "./buzzer" in the VM client, it outputs as bellows and exited.
root@syzkaller:~# ./buzzer
using strategy playground
func#0 @0
0: R1=ctx() R10=fp0
0: (b7) r0 = 0 ; R0_w=0
1: (95) exit
processed 2 insns (limit 1000000) max_states_per_insn 0 total_states 0 peak_states 0 mark_read 0
In addition, I can only see "404 page not found" on the webpage http://localhost:8080/.
Could you please release a compiled binary buzzer in the repo, so that I can check my running environment to eliminate other interference factors?
You are one step away from your goal. Run it with the flag -strategy=pointer_arithmetic
and then should be good.
The default behaviour now is the “playground” strategy. Which allows you to test ebpf programs.
You can see the code at pkg/strategies
Yes, it works now with the flag -strategy
.
When running buzzer, I can see ebpf-bin-xxx
, verifier-log-xxx
files are written to the /tmp
directory. Maybe I didn't see it clearly,I didn't see how to get the bug samples and reproduce it in the readMe
file, could you give me some advices?
Also, I would like to ask if I can run buzzer on aarch64
platform (such as Android devices
). If not, theoretically, can it be successfully ported without too much work?
Have you considered combining buzzer and syzkaller
recently?
When running buzzer, I can see ebpf-bin-xxx, verifier-log-xxx files are written to the /tmp directory. Maybe I didn't see it clearly,I didn't see how to get the bug samples and reproduce it in the readMe file, could you give me some advices?
That strategy was deprecated, it wasn't reliably finding things.
Also, I would like to ask if I can run buzzer on aarch64 platform (such as Android devices). If not, theoretically, can it be successfully ported without too much work?
Theoretically yes it should be possible. That being said as far as I have seen, ebpf code is arch independent. So I am not so sure about any benefits of this. Other than checking for un patched known vulnerabilities.
Have you considered combining buzzer and syzkaller recently?
We are working on it :)
Hey, I ran buzzer for two days, and it reported this OOM error as shown below, the buzzer has stopped now. I am new and not familiar with ebpf, does this mean that buzzer has found an OOM bug?
mark_precise: frame0: regs=r7 stack= before 473: (bc) w7 = w0
mark_precise: frame0: regs=r0 stack= before 472: (1f) r2 -= r1
mark_precise: frame0: regs=r0 stack= before 471: (5c) w5 &= w6
mark_precise: frame0: regs=r0 stack= before 470: (6c) w5 <<= w1
mark_precise: frame0: regs=r0 stack= before 354: (4e) if w5 & w4 goto pc+115
mark_precise: frame0: regs=r0 stack= before 353: (5f) r8 &= r4
mark_precise: frame0: regs=r0 stack= before 352: (6e) if w4 s> w4 goto pc+205
mark_precise: frame0: regs=r0 stack= before 351: (af) r5 ^= r4
mark_precise: frame0: regs=r0 stack= before 350: (54) w1 &= 1607884831
mark_precise: frame0: parent state regs= stack=: R0_r=P0xffffffffcf8b53e5 R1_r=P0xffffffff8d914ea0 R2_rw=scalar() R3_rw=scalar() R4_rw=P0xe6bda75 R5_r=P237 R6_rw=Pscalar() R0
math between map_value pointer and 3482014693 is not allowed
processed 63 insns (limit 1000000) max_states_per_insn 0 total_states 5 peak_states 5 mark_read 3
[74942.488821] buzzer invoked oom-killer: gfp_mask=0x2dc2(GFP_KERNEL|__GFP_HIGHMEM|__GFP_NOWARN|__GFP_ZERO), order=0, oom_score_adj=0
[74942.489257] CPU: 1 PID: 295 Comm: buzzer Not tainted 6.10.0-rc1-00027-g4a4be1ad3a6e #2
[74942.489497] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
[74942.489747] Call Trace:
[74942.489828] <TASK>
[74942.489898] dump_stack_lvl+0xab/0xe0
[74942.490022] dump_header+0x102/0xc20
[74942.490139] ? _raw_spin_lock+0x80/0xe0
[74942.490260] ? ___ratelimit+0x99/0x460
[74942.490381] oom_kill_process+0x846/0xe20
[74942.490509] ? task_will_free_mem+0xac/0x650
[74942.490645] ? oom_badness+0x522/0x670
[74942.490765] out_of_memory+0x2cb/0x1af0
[74942.490888] ? __pfx_out_of_memory+0x10/0x10
[74942.491023] ? __pfx_mutex_trylock+0x10/0x10
[74942.491160] ? zone_reclaimable_pages+0x74f/0x8e0
[74942.491309] __alloc_pages_noprof+0x1884/0x1ec0
[74942.491455] ? sysvec_call_function_single+0x18/0xc0
[74942.491611] ? __pfx___alloc_pages_noprof+0x10/0x10
[74942.491763] ? sysvec_call_function_single+0x18/0xc0
[74942.491918] ? sysvec_call_function_single+0x18/0xc0
[74942.492071] ? sysvec_call_function_single+0x18/0xc0
[74942.492228] ? __sanitizer_cov_trace_switch+0x54/0x90
[74942.492387] ? policy_nodemask+0xeb/0x4b0
[74942.492516] alloc_pages_mpol_noprof+0xf2/0x330
[74942.492661] ? __pfx_alloc_pages_mpol_noprof+0x10/0x10
[74942.492823] ? __vmalloc_node_range_noprof+0xa43/0x1310
[74942.492986] ? __vmalloc_node_range_noprof+0xa4d/0x1310
[74942.493149] __vmalloc_node_range_noprof+0xa87/0x1310
[74942.493308] ? kcov_ioctl+0x4f/0x6a0
[74942.493425] ? __pfx___vmalloc_node_range_noprof+0x10/0x10
[74942.493595] ? __pfx_do_sys_openat2+0x10/0x10
[74942.493736] ? kcov_ioctl+0x4f/0x6a0
[74942.493852] vmalloc_user_noprof+0x9e/0xe0
[74942.493982] ? kcov_ioctl+0x4f/0x6a0
[74942.494111] kcov_ioctl+0x4f/0x6a0
[74942.494223] ? __pfx_kcov_ioctl+0x10/0x10
[74942.494351] __x64_sys_ioctl+0x1a1/0x210
[74942.494478] do_syscall_64+0xa6/0x1a0
[74942.494596] entry_SYSCALL_64_after_hwframe+0x77/0x7f
[74942.494756] RIP: 0033:0xaddb7f
[74942.494860] Code: Unable to access opcode bytes at 0xaddb55.
[74942.495032] RSP: 002b:00007f1fd0d6bde0 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
[74942.495262] RAX: ffffffffffffffda RBX: 000000c000052d08 RCX: 0000000000addb7f
[74942.495478] RDX: 0000000004000000 RSI: 0000000080086301 RDI: 0000000000000007
[74942.495693] RBP: 00007f1fd0d6be60 R08: 0000000000000000 R09: 0000000000000000
[74942.495909] R10: 0000000000000000 R11: 0000000000000246 R12: ffffffffffffffff
[74942.496124] R13: 0000000000000011 R14: 000000c0000061a0 R15: 0000000000004000
[74942.496342] </TASK>
[74942.496423] Mem-Info:
[74942.496498] active_anon:28 inactive_anon:4085877 isolated_anon:0
[74942.496498] active_file:0 inactive_file:2 isolated_file:0
[74942.496498] unevictable:0 dirty:0 writeback:0
[74942.496498] slab_reclaimable:5496 slab_unreclaimable:160365
[74942.496498] mapped:3455 shmem:4528 pagetables:8371
[74942.496498] sec_pagetables:0 bounce:0
[74942.496498] kernel_misc_reclaimable:0
[74942.496498] free:21069 free_pcp:25878 free_cma:0
[74942.498145] Node 0 active_anon:112kB inactive_anon:16343508kB active_file:0kB inactive_file:536kB unevictable:0kB isolated(anon):0kB isolated(file):0kB mapped:13952kB dirts
[74942.499063] Node 0 DMA free:15360kB boost:0kB min:12kB low:24kB high:36kB reserved_highatomic:0KB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB uneviB
[74942.499950] lowmem_reserve[]: 0 2891 17341 0
[74942.500113] Node 0 DMA32 free:52284kB boost:0kB min:2808kB low:5768kB high:8728kB reserved_highatomic:0KB active_anon:0kB inactive_anon:2752788kB active_file:252kB inactivB
[74942.501077] lowmem_reserve[]: 0 0 14450 0
[74942.501233] Node 0 Normal free:15096kB boost:65440kB min:79476kB low:94272kB high:109068kB reserved_highatomic:0KB active_anon:112kB inactive_anon:13590660kB active_file:2B
[74942.502191] lowmem_reserve[]: 0 0 0 0
[74942.502310] Node 0 DMA: 0*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 1*1024kB (U) 1*2048kB (M) 3*4096kB (M) = 15360kB
[74942.502731] Node 0 DMA32: 1*4kB (M) 2*8kB (UM) 1*16kB (M) 2*32kB (UM) 2*64kB (UM) 31*128kB (UM) 21*256kB (UM) 17*512kB (M) 21*1024kB (UM) 5*2048kB (UM) 0*4096kB = 50020kB
[74942.503281] Node 0 Normal: 740*4kB (ME) 436*8kB (ME) 533*16kB (ME) 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 14976kB
[74942.503721] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB
[74942.503974] 5299 total pagecache pages
[74942.504105] 0 pages in swap cache
[74942.504221] Free swap = 0kB
[74942.504312] Total swap = 0kB
[74942.504403] 5242750 pages RAM
[74942.504497] 0 pages HighMem/MovableOnly
[74942.504614] 796817 pages reserved
[74942.504720] Tasks state (memory values in pages):
[74942.504862] [ pid ] uid tgid total_vm rss rss_anon rss_file rss_shmem pgtables_bytes swapents oom_score_adj name
[74942.505186] [ 88] 0 88 10014 5356 192 395 4769 114688 0 -250 systemd-journal
[74942.505528] [ 102] 0 102 8985 2614 2569 45 0 102400 0 -1000 systemd-udevd
[74942.505867] [ 131] 0 131 1409 76 64 12 0 49152 0 0 cron
[74942.506221] [ 143] 0 143 55233 697 367 330 0 73728 0 0 rsyslogd
[74942.506580] [ 167] 0 167 24971 320 311 9 0 77824 0 0 dhclient
[74942.506943] [ 193] 0 193 3338 263 224 39 0 69632 0 -1000 sshd
[74942.507292] [ 194] 0 194 718 49 32 17 0 53248 0 0 agetty
[74942.507642] [ 195] 0 195 718 33 0 33 0 45056 0 0 agetty
[74942.508003] [ 196] 0 196 718 46 0 46 0 45056 0 0 agetty
[74942.508357] [ 197] 0 197 718 44 32 12 0 49152 0 0 agetty
[74942.508695] [ 198] 0 198 718 37 0 37 0 45056 0 0 agetty
[74942.509048] [ 199] 0 199 718 47 32 15 0 40960 0 0 agetty
[74942.509430] [ 200] 0 200 2085 170 128 42 0 57344 0 0 login
[74942.509747] [ 206] 0 206 1513 130 128 2 0 49152 0 0 bash
[74942.510084] [ 290] 0 290 4380473 4074290 4074252 38 0 32886784 0 0 buzzer
[74942.510434] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,task=buzzer,pid=290,uid=0
[74942.510758] Out of memory: Killed process 290 (buzzer) total-vm:17521892kB, anon-rss:16297008kB, file-rss:152kB, shmem-rss:0kB, UID:0 pgtables:32116kB oom_score_adj:0
[74944.737960] oom_reaper: reaped process 290 (buzzer), now anon-rss:112kB, file-rss:24kB, shmem-rss:0kB
Killed
Have you considered combining buzzer and syzkaller recently? We are working on it :)
It is interesting to integrate buzzer and syzkaller, and I noticed that you have a plan (https://github.com/google/buzzer/issues/19) May I know when this feature will be launched?
Thank you for your patience.
Hey, I ran buzzer for two days, and it reported this OOM error as shown below, the buzzer has stopped now. I am new and not familiar with ebpf, does this mean that buzzer has found an OOM bug?
No, buzzer can be quite memory hungry if the ebpf programs it generates are a bit big. I'd recommend increasing your vm's ram, if that doesn't solve the issue then it is a problem with some memory leak in buzzer itself
May I know when this feature will be launched? We don't have a timeline yet but we will update the github issue once we do.
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:
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.