On 12/14/2010 07:53 PM, Hollis Blanchard wrote:
On 12/14/2010 12:48 AM, Avi Kivity wrote:
On 12/13/2010 07:17 PM, Hollis Blanchard wrote:
Rewriting is dangerous if the guest is unaware of it. As soon as
it is made aware of it, it might as well actually do it in the best
way that suits it.
Can you list some examples of dangerous scenarios?
Perhaps I should rephrase... any real-world dangerous scenarios? :)
That's much less fun.
I was hoping you could share some traps you've hit with Linux or
Windows on x86.
We've hit a lot of issues with the very limited patching we do for
Windows XP (Linux does its own patching):
- Windows hibernation saves the patched code, but not the payload, so we
have to set up hooks to re-enable the payload when Windows resumes from
hibernation
- We need the vcpu id in the payload code, and no easy way to get at
it. After several wierd hacks we settled on peeking at the Windows
processor control block, a guest specific per-cpu data structure.
- Some patched instructions are called before the stack is set up, so
the return doesn't work very well
- others I'm suppressing
- guest checksums own kernel pages
For runtime intrusion detection? Such guests can simply not ask the
hypervisor to enable the rewriting feature.
Which is sad.
- clever compiler reuses code for constant pool
Not sure what you mean here. Anyways I think clever compilers are
irrelevant, since a compiler will not ordinarily emit a
supervisor-mode instruction. The hypervisor has no need to patch
normal user-mode instructions.
I meant a really clever compiler. And by using code for the constant
pool I using IP-relative addressing to fetch a constant using a small
offset. If the constant happens to be a patched instruction, it won't
be so constant.
- guest patches itself (a la linux alternatives), surprised when it
sees a different instruction
PowerPC Linux does patch itself, which is a write-only operation.
Other self-patchers might be different; say you use xor to toggle
between two variants, reducing the amount of data you need to keep for
patching.
- guest jits own kernel code (like Singularity), gets confused when
it reads back something it didn't write
This is getting really hypothetical, but why would a JIT need to read
the generated code?
Any wierd hypothetical idea will be in mission-critical production use
somewhere, see Andreas reply.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
