[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Fetching instructions after page-fault, near page boundary?
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 exactlythe 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 sameinstruction.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 finishthis 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 -- MatsRegards, Anthony Liguori Petersson, Mats wrote:If we get a page-fault due to a MMIO access to a virtualMMIO device(such as VGA screen in HVM), we shouldn't need to worryabout crossingthe page-boundary at the end of the instruction, right?Let's say theeither we failinstruction is a 7-byte instruction like this: xxxx1FFD: 11 22 33 <page boundary to page xxxx2000> 44 55 66 77If the page xxxx2000 isn't present when the instruction is started, then we'd FIRST get a page-fault for this address, sothe instruction (if xxxx2000 page isn't actually possibleto be fixedup), or we get the page fixed up and therefore the secondtime, whenwe 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 goinground modifyingthe page-tables for this guest domain - which I don't thinkis a VALIDempty(unusedthing to expect, is it?]Next case is where we have a short instruction before anpage), say a three-byte instruction (RR is anotherinstructon, such asreadable sincea return instruction).xxx1FFC: 11 22 33 RR <page boundary to xxxx2000> [notreadable,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 notI'll just cut the number of bytes short, assuming that the valid instruction is shorter than 15 bytes.setup, whichDoes anyone see a problem with this method?[By the way, this makes an improvement over the currentfails 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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |