[Xen-devel] Notes from Design Summit Hypervisor Fuzzing Session

[Lars Kurth <lars.kurth.xen@xxxxxxxxx>]

Hi all,
please find attached my notes. A lot of it went over my head, so I may have 
gotten things wrong and some are missing
Feel free to modify, chip in, clarify, as needed
Lars

Session URL: http://sched.co/AjHN

OPTION 1: Userspace Approach
============================

 Dom0  Domu
[AFL] [VM nested with Xen and XTF]
[Xen                             ]

Would need 
1. nested HVM support
2. VM forking

Not an option as too hard

OPTION 2:
=========

 Dom0            DomU
[AFL   ]        [VM XTF   ] 
[      ] <----> [  [e]    ] e = executor
   /\              ||
   ||              \/
[Xen                      ]

This approach would need

1. Tracing (instrument binary and write to shared memory for AFL)

Almost done, but not completely deterministic yet

2. Implemented a special hypercall that returns return code that can be 
converted into expected AFL output for branching info

Submitted

3. Communication channel between AFL and XTF

Almost done

4. Using XTF because it should be the fastest option and allows us to restrict 
the scope of what to fuzz

Key challenge: not making unnecessary indeterministic hyper calls in the 
background
Use of XTF constrains the degrees of freedom and focusses the fuzzing

5. Need some way to feed info back into AFL

I believe there was some discussion around this, which I did not get

Discussion
==========

Dismissed Option 1. All agreed that Option 2 is best.

I missed quite a bit of this, because the discussion was quite fast at times

George: 
recommends to test one thing at the time to reduce the problem space
Such as iteration, feedback, ...  
Based on outcome iterate

There was a little bit of discussion around determinism:

Andy: blacklist shadop_??? with ??? = shutdown, suspend, watchdog, ... 
Possibly there are some more functions that need to be blacklisted
This should help with determinism

Andy: Going to have problems such as dealing with partial hypercall operations
Wei: Already included this - only 1 thread in XTF => deterministic
Andy: What happoens if HV gets interrupted
Juergen: put XTF into null scheduler pool to minimise risk of interrupts and 
increase determinism
Wei: That would exclude IRQs in such a scenario

There was a little bit of around feedback loop and protocol between AFL and XTF

Andy: easiest way to get a feedback loop starting. XTF to boot, wait on event 
channel (shadop call with - 0 timeout)
AFL does the hypercall with edge tracing, ...

Jurgen: starting measurement can be done be initiated AFL (Dom0), and disabled 
from XTF (DomU)
Wei: follow the same pattern as xl already does (I don't know the sample code 
though)

There was a bit of discussion on the impact pf QEMU

Wei: can't use QEMU to emulate a machine with vhdx (following on from a 
question by Ian)

Ian: this will be fast, not quite so reliable. But a good first step

And some other topics

Andy: there is also syzkaller, with fuzzing entity being some userspace calls
Wei: used as a reference material as Oracle did something similar
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel