VMM patches interfere with guest analysis of ring-0 code (e.g. Ksplice)

[Anders Kaseorg]

The attached Linux kernel module executes the instruction sequence:

PUSHF; CLI; NOP; NOP; NOP; NOP; POPF

and then reads the code it just executed and logs those 7 bytes.

Under VirtualBox 2.2.4 r47978 with VT-x/AMD-V disabled, when this module is compiled and loaded in an Ubuntu 9.04 i386 guest, it outputs:

Before: 9c fa 90 90 90 90 9d
After: 9c e9 69 db b1 ff 9d

That is, the CLI was overwritten by a CALL instruction. This demonstrates that the VMM-generated patches are visible to the guest.

This can interfere with guest analysis of ring-0 code. In particular, this problem was discovered while trying to apply Ksplice updates to a VirtualBox guest. Ksplice attempts to match the code in the running kernel with the expected original code before patching it to ensure safety (see ​http://www.ksplice.com/paper for details), but the VMM-generated patches cause this matching to fail and the update to be aborted.

Recent Linux kernel features such as ftrace and kprobes may be affected by this as well.

[Anders Kaseorg]

test kernel module

[Sander van Leeuwen]

That's the way VirtualBox works in software virtualization mode. If it bothers you, switch to VT-x or AMD-V.

[Anders Kaseorg]

For users that don’t have VT-x/AMD-V available, is there an option they can set to get more accurate emulation?

Alternatively, is there a workaround Ksplice could use to ensure that it is reading the unmodified code? (I have observed, for example, that the modification disappears temporarily if you write into part of the patched region, but obviously that destroys information, and also has a race condition.)