Re: [patch] kvm: make cr3 loading more robust

[Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>]

Ingo Molnar wrote:
>> That's a good solution.  I don't see why it has to be made 
>> non-writable -- it has undefined content, and any old value will do.  
>> We have (or maybe had) something like that somewhere.
>>     
>
> it should always return 0xff content because that's how real hardware 
> behaves. It's essentially ROM-alike, with 0xff content. Writes are 
> ignored. (last i checked)
>
>   

Still, software can't depend on it (maybe some old stuff does to get the 
end of memory).  You can't randomly poke at memory.


> also having it writable means it's an information leak as we want to 
> share this page amongst guests, etc. Then explicitly faulting the guest 
> would be alot cleaner.
>   

We can have a per-vm page.

>   
>> An alternative is to add a flag to the vcpu which would be examined on 
>> entry (vcpu->triple_faulted).
>>     
>
> well, the triple fault isnt really explicit behavior of the cr3 loading, 
> it is "just" a side-effect of having an all-0xff piece of physical 
> memory holding the CPU's page tables. Such a cr3 can be loaded fine, but 
> the next instruction fetched will be 0xff 0xff, which should be an 
> undefined opcode. The resulting fault will try to execute based off an 
> invalid IDT so we get a double fault, which then also tries to execute 
> 0xff 0xff (if the IDT entry didnt generate a #GPF beforehand, due to an 
> invalid segment descriptor) so it results in a triple fault. 

It's an optimization then :)

> Does VMX 
> report triple faults?
>   

Yes.

If we add a "read-only memory slot" abstraction we can use it for the 
unwired address space.

Note that the corner cases will never be 100% emulatable.  For example, 
you can set cr3 to point at your IDE DMA mmio space or something like 
that.  It's quite all right to kill the guest quietly at that point, as 
no real-life guest will do that.

The kvm goals do not include cycle accurate emulation.  We want to be 
reasonably close to real hardware for the real-life uses.  I'd like to 
get the other cases right too, but not at the expense of simplicity and 
correctness.  Of course, it has to be secure even in non-real-life 
situations.

-- 
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV