google / buzzer

Apache License 2.0
423 stars 30 forks source link

Run buzzer in the vm and get "Fuzzer run no 0" #58

Closed Clingto closed 4 months ago

Clingto commented 4 months ago

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.

Clingto commented 4 months ago

The host machine is ubuntu 22.04, and the VM is the latest linux kernel.

thatjiaozi commented 4 months ago

Hi!

i think you might have an outdated version of the repo. Could you git pull and try again?

Clingto commented 4 months ago

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?

thatjiaozi commented 4 months ago

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

Clingto commented 4 months ago

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?

thatjiaozi commented 4 months ago

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 :)

Clingto commented 4 months ago

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.

thatjiaozi commented 4 months ago

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.