From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: Fetching instructions after page-fault, near page boundary? Date: Fri, 02 Jun 2006 15:35:56 -0500 Message-ID: <4480A12C.3090601@us.ibm.com> References: <907625E08839C4409CE5768403633E0BA7FCE1@sefsexmb1.amd.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <907625E08839C4409CE5768403633E0BA7FCE1@sefsexmb1.amd.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: "Petersson, Mats" Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org 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 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 [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 >>> >>> >> >> > >