[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC][PATCH] x86: CS limit checks
From: |
Jan Kiszka |
Subject: |
Re: [Qemu-devel] [RFC][PATCH] x86: CS limit checks |
Date: |
Thu, 17 Jul 2008 18:10:55 +0200 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 |
Paul Brook wrote:
> On Thursday 17 July 2008, Jan Kiszka wrote:
>> Paul Brook wrote:
>>> On Thursday 17 July 2008, Jan Kiszka wrote:
>>>> + if (s->pc < s->cs_base || s->pc - s->cs_base > s->cs_limit) {
>>>> + /* At least some of the opcode fetches violate the CS limit.
>>>> + Overwrite the generated code with a GPF raising one. */
>>>> + gen_opc_ptr = gen_opc_start;
>>>> + gen_opparam_ptr = gen_opparam_start;
>>>> + gen_exception(s, EXCP0D_GPF, pc_start - s->cs_base);
>>>> + }
>>> I'm fairly sure this is wrong. The TB may fault before it gets to the end
>>> of the segment. Likewise if the instruction spanning the limit happens to
>>> be an illegal op you will generate the wrong kind of exception.
>> What a pity, it looked so easy. OK, will think about those aspects
>> again. BTW, what happens when the translator hits an unresolvable
>> address and faults?
>
> Looks like that's also broken. In practice I guess a page fault occuring
> early is usually less harmful than a GPF.
To me it looks like as if the generator can so far raise a PF
prematurely when it steps on an invalid code address while building a
new TB. This probably has to fix the same way as the limit check is
realized: by injecting an exception (PF or GP) into the generated code
at the correct PC. Hmm, the PF-during-translation issue is probably not
just limited to x86...
Jan
--
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux
Re: [Qemu-devel] [RFC][PATCH] x86: CS limit checks, Fabrice Bellard, 2008/07/17