Re: [Xen-devel] Fetching instructions after page-fault, near page boundary?

[Anthony Liguori <aliguori@xxxxxxxxxx>]

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@xxxxxxxxxxxxxxxxxxx
> > > http://lists.xensource.com/xen-devel
> > >   
> > >       
> >     
>   
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel