syzkaller

syzkaller copied to clipboard

It seems that use of UML (user mode linux) could be beneficial for kernel fuzzing by making it consume less memory, boot faster, not require a vmm, etc. Also this time travel feature looks extremely cool and could save lots of resources: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=065038706f77a56754e8f0c2556dab7e22dfe577 Need to investigate if UML will work for us, why not, how, write docs.

Heh, making some waves. I was planning to write a paper on it ("time travel" mode), but haven't gotten around to it.

FWIW, I think we want to port the ORC unwinder to UML, I was planning to take a look at it eventually, but no promises.

I'm not sure if syzcaller would really benefit much though, since I doubt it's typically doing much that's time dependent? In my first PoC (hostapd/wpa_s wifi tests) it helps a LOT because we do a lot of things that really need to wait, like a 2 minute wait for radar events that will never happen, which of course gets compressed way down with this mode.

Need to investigate if UML will work for us, why not, how, write docs.

One downside is loosing a lot of attack surface since UML is strictly UP and not preemptive.

FWIW, I think we want to port the ORC unwinder to UML, I was planning to take a look at it eventually, but no promises.

Is it a prerequisite for something? We use FP unwinder and it works fine. We could continue using it for UML as well.

I'm not sure if syzcaller would really benefit much though, since I doubt it's typically doing much that's time dependent?

It should. Random programs tend to hang a lot and then there is no other way around than waiting for a timeout. Consider we just create a pipe and try to read from it.

One downside is loosing a lot of attack surface since UML is strictly UP and not preemptive.

This is not going to be the only mode. It's an additional mode. So it will open more test surface.

Looking at UML configs, it does not support KASAN. While syzkaller does not require KASAN, it is a prerequisite for continuous testing on syzbot.

FWIW, I think we want to port the ORC unwinder to UML, I was planning to take a look at it eventually, but no promises.

Is it a prerequisite for something? We use FP unwinder and it works fine. We could continue using it for UML as well.

Not really. I just like the enhanced accuracy. If you use FP I guess it works just as well though.

I'm not sure if syzcaller would really benefit much though, since I doubt it's typically doing much that's time dependent?

It should. Random programs tend to hang a lot and then there is no other way around than waiting for a timeout. Consider we just create a pipe and try to read from it.

Hmm, good point.

One downside is loosing a lot of attack surface since UML is strictly UP and not preemptive.

This is not going to be the only mode. It's an additional mode. So it will open more test surface.

:-)

Looking at UML configs, it does not support KASAN. While syzkaller does not require KASAN, it is a prerequisite for continuous testing on syzbot.

I guess that can be fixed too. I looked at it very briefly at some point but didn't really dig into it and didn't get anywhere.

FTR as of 6.4, UML does not run with CONFIG_KCOV.

A fix from @ramosian-glider:

diff --git a/arch/um/drivers/Makefile b/arch/um/drivers/Makefile
index a461a950f0518..9cf10eec31931 100644
--- a/arch/um/drivers/Makefile
+++ b/arch/um/drivers/Makefile
@@ -6,6 +6,8 @@
 # pcap is broken in 2.5 because kbuild doesn't allow pcap.a to be linked
 # in to pcap.o
 
+KCOV_INSTRUMENT := n
+
 slip-objs := slip_kern.o slip_user.o
 slirp-objs := slirp_kern.o slirp_user.o
 daemon-objs := daemon_kern.o daemon_user.o
diff --git a/lib/Makefile b/lib/Makefile
index 42d307ade225e..00cfbeb205eec 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -15,6 +15,9 @@ KCOV_INSTRUMENT_debugobjects.o := n
 KCOV_INSTRUMENT_dynamic_debug.o := n
 KCOV_INSTRUMENT_fault-inject.o := n
 
+# UML builds call vsprintf before kcov is initialized.
+KCOV_INSTRUMENT_vsprintf.o := n
+
 # string.o implements standard library functions like memset/memcpy etc.
 # Use -ffreestanding to ensure that the compiler does not try to "optimize"
 # them into calls to themselves.