https://bugzilla.kernel.org/show_bug.cgi?id=103131 Bug ID: 103131 Summary: Forgotten stack pushes with KVM_MEM_READONLY Product: Virtualization Version: unspecified Kernel Version: 4.1.5 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: kvm Assignee: virtualization_kvm@xxxxxxxxxxxxxxxxxxxx Reporter: felix.von.s@xxxxxxxxx Regression: No Created attachment 185201 --> https://bugzilla.kernel.org/attachment.cgi?id=185201&action=edit Test program (C99) I found this bug when I wanted to use KVM_MEM_READONLY to capture all memory writes in my hypervisor. Attached test program output when ran with the argument "0" (no flags): > vm exit from f000:0000f006 [cs base 0x000f0000, pc=0x000ff006] > io: out 2 bytes x1 @0xbeef: fa 7f > vm exit from f000:0000fffb [cs base 0x000f0000, pc=0x000ffffb] > halted Output when ran with "2" (KVM_MEM_READONLY): > vm exit from f000:0000f000 [cs base 0x000f0000, pc=0x000ff000] > write 2 bytes at 0x7ffa: fa ff 00 00 00 00 00 00 > vm exit from f000:0000f006 [cs base 0x000f0000, pc=0x000ff006] > io: out 2 bytes x1 @0xbeef: fa 7f > vm exit from f4f4:0000fffa [cs base 0x000f4f40, pc=0x00104f3a] > internal error, suberror 0x1 In real mode, doing an INT call is roughly equivalent to pushing the flags register, CS, IP and then jumping to the appropriate handler listed in the IVT. As you can see from above, when KVM_MEM_READONLY flag is set, only the "pushing IP" part is captured by the hypervisor; the other memory writes are forgotten (although the stack pointer is updated accordingly). This causes a later IRET to return to the wrong segment (never mind with the wrong flags) and the virtual machine to crash. I don't know if there are any security implications; I quite doubt it to be honest, but if anyone wants to design a cutesy logo, please do. -- You are receiving this mail because: You are watching the assignee of the bug. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
