Re: Fetching instructions after page-fault, near page boundary?

[Anthony Liguori <aliguori@us.ibm.com>]

Petersson, Mats wrote:
> Ah, yet another place where segments show their "ugly" head.... And the
> current code is not doing this very well... In fact, it assumes that
> non-real-mode segments have base=0 and that the limit "is big enough".
>
> Although, in a normal system, that sort of violation would be caught by
> the processor itself [GP faulting the instruction] before we get the
> page-fault, unless:
> 1. Someone is modifying the instructions we're emulating - and that
> would have to be done at exactly the right time for the page-fault to be
> in transit in Xen, but not yet read the data from the page - which I'm
> sure someone can figure out how to do [it's actually several thousand
> cycles, so it's not exactly a tiny hole as such], but it's not exactly
> the most likely attack scenario I can think of. 
>
> 2. Someone is updating the descriptor tables between the processor
> executing the original trapping instruction, and us emulating the same
> instruction. 
>
> However, I think we should START this project [moving
> x86_emulate_memop() into QEMU] by aiming to achieve something that is
> better than the current solution - not fill every hole and gap possible
> all in one go. So do you think it's fair to say that we can make a note
> of this lack of security and ignore it for now? [Otherwise, I fear that
> I will be moved to another project before I even get a chance to finish
> this project]. 
>   

heh, sure, I think that's fine :-)

I haven't been able to think of a way to actually exploit this FWIW.  
It's certainly a correctness issue so we should eventually address it 
but for now I think it's fine to just sweep it under the table.

Regards,

Anthony Liguori

> --
> Mats
>   
>> Regards,
>>
>> Anthony Liguori
>>
>> Petersson, Mats wrote:
>>     
>>> If we get a page-fault due to a MMIO access to a virtual 
>>>       
>> MMIO device 
>>     
>>> (such as VGA screen in HVM), we shouldn't need to worry 
>>>       
>> about crossing 
>>     
>>> the page-boundary at the end of the instruction, right? 
>>>       
>> Let's say the 
>>     
>>> instruction is a 7-byte instruction like this:
>>>
>>> xxxx1FFD: 11 22 33 <page boundary to page xxxx2000> 44 55 66 77
>>>
>>> If the page xxxx2000 isn't present when the instruction is started, 
>>> then we'd FIRST get a page-fault for this address, so 
>>>       
>> either we fail 
>>     
>>> the instruction (if xxxx2000 page isn't actually possible 
>>>       
>> to be fixed 
>>     
>>> up), or we get the page fixed up and therefore the second 
>>>       
>> time, when 
>>     
>>> we get to the page-fault handler looking at the address the 
>>> instruction is accessing [doing the MMIO part], the second page is 
>>> present [assuming we haven't got any sneaky code going 
>>>       
>> round modifying 
>>     
>>> the page-tables for this guest domain - which I don't think 
>>>       
>> is a VALID 
>>     
>>> thing to expect, is it?]
>>>
>>> Next case is where we have a short instruction before an 
>>>       
>> empty(unused 
>>     
>>> page), say a three-byte instruction (RR is another 
>>>       
>> instructon, such as 
>>     
>>> a return instruction).
>>>
>>> xxx1FFC: 11 22 33 RR <page boundary to xxxx2000> [not 
>>>       
>> readable since 
>>     
>>> it's not present].
>>>
>>>
>>> My design idea for the merged x86_emulate.c in QEMU is to read 
>>> instruction bytes blind (i.e. not knowing the actual instruction 
>>> length) by the this method:
>>> Try to read 15 bytes (MAX_INST_LEN), and if the instruction bytes 
>>> happen to cross a page-boundary, and the second page is not 
>>>       
>> readable, 
>>     
>>> I'll just cut the number of bytes short, assuming that the valid 
>>> instruction is shorter than 15 bytes.
>>>
>>> Does anyone see a problem with this method?
>>>
>>> [By the way, this makes an improvement over the current 
>>>       
>> setup, which 
>>     
>>> fails if we try to read a page that isn't readable - which at least 
>>> the SVM model does try sometimes].
>>>
>>> --
>>> Mats
>>>
>>>
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xensource.com
>>> http://lists.xensource.com/xen-devel
>>>   
>>>       
>>
>>     
>
>