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


Anthony Liguori


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


Xen-devel mailing list

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.