Re: [Qemu-devel] [RFC][PATCH] x86: CS limit checks

[Jan Kiszka <jan.kiszka@siemens.com>]

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