1*e9d95d01SStefan Hajnoczi======================= 2*e9d95d01SStefan HajnocziSecure Coding Practices 3*e9d95d01SStefan Hajnoczi======================= 4*e9d95d01SStefan HajnocziThis document covers topics that both developers and security researchers must 5*e9d95d01SStefan Hajnoczibe aware of so that they can develop safe code and audit existing code 6*e9d95d01SStefan Hajnocziproperly. 7*e9d95d01SStefan Hajnoczi 8*e9d95d01SStefan HajnocziReporting Security Bugs 9*e9d95d01SStefan Hajnoczi----------------------- 10*e9d95d01SStefan HajnocziFor details on how to report security bugs or ask questions about potential 11*e9d95d01SStefan Hajnoczisecurity bugs, see the `Security Process wiki page 12*e9d95d01SStefan Hajnoczi<https://wiki.qemu.org/SecurityProcess>`_. 13*e9d95d01SStefan Hajnoczi 14*e9d95d01SStefan HajnocziGeneral Secure C Coding Practices 15*e9d95d01SStefan Hajnoczi--------------------------------- 16*e9d95d01SStefan HajnocziMost CVEs (security bugs) reported against QEMU are not specific to 17*e9d95d01SStefan Hajnoczivirtualization or emulation. They are simply C programming bugs. Therefore 18*e9d95d01SStefan Hajnocziit's critical to be aware of common classes of security bugs. 19*e9d95d01SStefan Hajnoczi 20*e9d95d01SStefan HajnocziThere is a wide selection of resources available covering secure C coding. For 21*e9d95d01SStefan Hajnocziexample, the `CERT C Coding Standard 22*e9d95d01SStefan Hajnoczi<https://wiki.sei.cmu.edu/confluence/display/c/SEI+CERT+C+Coding+Standard>`_ 23*e9d95d01SStefan Hajnoczicovers the most important classes of security bugs. 24*e9d95d01SStefan Hajnoczi 25*e9d95d01SStefan HajnocziInstead of describing them in detail here, only the names of the most important 26*e9d95d01SStefan Hajnocziclasses of security bugs are mentioned: 27*e9d95d01SStefan Hajnoczi 28*e9d95d01SStefan Hajnoczi* Buffer overflows 29*e9d95d01SStefan Hajnoczi* Use-after-free and double-free 30*e9d95d01SStefan Hajnoczi* Integer overflows 31*e9d95d01SStefan Hajnoczi* Format string vulnerabilities 32*e9d95d01SStefan Hajnoczi 33*e9d95d01SStefan HajnocziSome of these classes of bugs can be detected by analyzers. Static analysis is 34*e9d95d01SStefan Hajnocziperformed regularly by Coverity and the most obvious of these bugs are even 35*e9d95d01SStefan Hajnoczireported by compilers. Dynamic analysis is possible with valgrind, tsan, and 36*e9d95d01SStefan Hajnocziasan. 37*e9d95d01SStefan Hajnoczi 38*e9d95d01SStefan HajnocziInput Validation 39*e9d95d01SStefan Hajnoczi---------------- 40*e9d95d01SStefan HajnocziInputs from the guest or external sources (e.g. network, files) cannot be 41*e9d95d01SStefan Hajnoczitrusted and may be invalid. Inputs must be checked before using them in a way 42*e9d95d01SStefan Hajnoczithat could crash the program, expose host memory to the guest, or otherwise be 43*e9d95d01SStefan Hajnocziexploitable by an attacker. 44*e9d95d01SStefan Hajnoczi 45*e9d95d01SStefan HajnocziThe most sensitive attack surface is device emulation. All hardware register 46*e9d95d01SStefan Hajnocziaccesses and data read from guest memory must be validated. A typical example 47*e9d95d01SStefan Hajnocziis a device that contains multiple units that are selectable by the guest via 48*e9d95d01SStefan Hajnoczian index register:: 49*e9d95d01SStefan Hajnoczi 50*e9d95d01SStefan Hajnoczi typedef struct { 51*e9d95d01SStefan Hajnoczi ProcessingUnit unit[2]; 52*e9d95d01SStefan Hajnoczi ... 53*e9d95d01SStefan Hajnoczi } MyDeviceState; 54*e9d95d01SStefan Hajnoczi 55*e9d95d01SStefan Hajnoczi static void mydev_writel(void *opaque, uint32_t addr, uint32_t val) 56*e9d95d01SStefan Hajnoczi { 57*e9d95d01SStefan Hajnoczi MyDeviceState *mydev = opaque; 58*e9d95d01SStefan Hajnoczi ProcessingUnit *unit; 59*e9d95d01SStefan Hajnoczi 60*e9d95d01SStefan Hajnoczi switch (addr) { 61*e9d95d01SStefan Hajnoczi case MYDEV_SELECT_UNIT: 62*e9d95d01SStefan Hajnoczi unit = &mydev->unit[val]; <-- this input wasn't validated! 63*e9d95d01SStefan Hajnoczi ... 64*e9d95d01SStefan Hajnoczi } 65*e9d95d01SStefan Hajnoczi } 66*e9d95d01SStefan Hajnoczi 67*e9d95d01SStefan HajnocziIf ``val`` is not in range [0, 1] then an out-of-bounds memory access will take 68*e9d95d01SStefan Hajnocziplace when ``unit`` is dereferenced. The code must check that ``val`` is 0 or 69*e9d95d01SStefan Hajnoczi1 and handle the case where it is invalid. 70*e9d95d01SStefan Hajnoczi 71*e9d95d01SStefan HajnocziUnexpected Device Accesses 72*e9d95d01SStefan Hajnoczi-------------------------- 73*e9d95d01SStefan HajnocziThe guest may access device registers in unusual orders or at unexpected 74*e9d95d01SStefan Hajnoczimoments. Device emulation code must not assume that the guest follows the 75*e9d95d01SStefan Hajnoczitypical "theory of operation" presented in driver writer manuals. The guest 76*e9d95d01SStefan Hajnoczimay make nonsense accesses to device registers such as starting operations 77*e9d95d01SStefan Hajnoczibefore the device has been fully initialized. 78*e9d95d01SStefan Hajnoczi 79*e9d95d01SStefan HajnocziA related issue is that device emulation code must be prepared for unexpected 80*e9d95d01SStefan Hajnoczidevice register accesses while asynchronous operations are in progress. A 81*e9d95d01SStefan Hajnocziwell-behaved guest might wait for a completion interrupt before accessing 82*e9d95d01SStefan Hajnoczicertain device registers. Device emulation code must handle the case where the 83*e9d95d01SStefan Hajnocziguest overwrites registers or submits further requests before an ongoing 84*e9d95d01SStefan Hajnoczirequest completes. Unexpected accesses must not cause memory corruption or 85*e9d95d01SStefan Hajnoczileaks in QEMU. 86*e9d95d01SStefan Hajnoczi 87*e9d95d01SStefan HajnocziInvalid device register accesses can be reported with 88*e9d95d01SStefan Hajnoczi``qemu_log_mask(LOG_GUEST_ERROR, ...)``. The ``-d guest_errors`` command-line 89*e9d95d01SStefan Hajnoczioption enables these log messages. 90*e9d95d01SStefan Hajnoczi 91*e9d95d01SStefan HajnocziLive Migration 92*e9d95d01SStefan Hajnoczi-------------- 93*e9d95d01SStefan HajnocziDevice state can be saved to disk image files and shared with other users. 94*e9d95d01SStefan HajnocziLive migration code must validate inputs when loading device state so an 95*e9d95d01SStefan Hajnocziattacker cannot gain control by crafting invalid device states. Device state 96*e9d95d01SStefan Hajnocziis therefore considered untrusted even though it is typically generated by QEMU 97*e9d95d01SStefan Hajnocziitself. 98*e9d95d01SStefan Hajnoczi 99*e9d95d01SStefan HajnocziGuest Memory Access Races 100*e9d95d01SStefan Hajnoczi------------------------- 101*e9d95d01SStefan HajnocziGuests with multiple vCPUs may modify guest RAM while device emulation code is 102*e9d95d01SStefan Hajnoczirunning. Device emulation code must copy in descriptors and other guest RAM 103*e9d95d01SStefan Hajnoczistructures and only process the local copy. This prevents 104*e9d95d01SStefan Hajnoczitime-of-check-to-time-of-use (TOCTOU) race conditions that could cause QEMU to 105*e9d95d01SStefan Hajnoczicrash when a vCPU thread modifies guest RAM while device emulation is 106*e9d95d01SStefan Hajnocziprocessing it. 107