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_...@kernel-bugs.osdl.org
Reporter: felix.vo...@posteo.de
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
