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

["Petersson, Mats" <Mats.Petersson@xxxxxxx>]

> -----Original Message-----
> From: Anthony Liguori [mailto:aliguori@xxxxxxxxxx] 
> Sent: 02 June 2006 21:16
> To: Petersson, Mats
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Xen-devel] Fetching instructions after 
> page-fault, near page boundary?
> 
> I would think you would not only have to worry about crossing 
> page boundaries, but also crossing a segment descriptor 
> limit.  These days, segmentation is used for some security 
> purposes (to emulate a NX bit for instance).

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]. 

--
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