Re: re-writing on powerpc

[Avi Kivity <avi@redhat.com>]

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