qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] target-i386: fix segment limit check in ljmp


From: Andrew Oates
Subject: Re: [Qemu-devel] [PATCH] target-i386: fix segment limit check in ljmp
Date: Mon, 20 Aug 2018 07:32:13 -0400

On Mon, Aug 20, 2018 at 6:06 AM Paolo Bonzini <address@hidden> wrote:
>
> On 17/08/2018 20:04, Andrew Oates wrote:
> >>> [1] this is an invalid configuration (in protected mode the L bit is
> >>> reserved and should be set to zero), but qemu doesn't enforce that.
> >
> > Is there a central place to do that sort of validation?  We could do it
> > in load_segment_ra, but that doesn't feel quite right.  Otherwise it's
> > whack-a-mole to check validity at every place a code segment is
> > referenced---but maybe that's ok, there probably aren't too many of them.
> >
> > WDYT?
>
> To find them you have to look for the calls to cpu_x86_load_seg_cache.
>
> However, the L bit is simply ignored in the descriptor cache outside
> 64-bit mode (at least that's what you can guess from the Intel manual's
> 26.3 CHECKING AND LOADING GUEST STATE, which is as close as you can get
> to an official explanation of the descriptor cache), so you'd have to
> take that into account too and do the check in the callers of
> cpu_x86_load_seg_cache.
>
> And in fact, the wording is a bit wishy-washy in both the Intel and AMD
> manuals, for example AMD says of bit 21 that
>
>         Generally, software should clear all reserved bits to 0, so they
>         can be defined in future revisions to the AMD64 architecture.
>
> so I am not 100% sure that the processor will actually raise an
> exception if L is 1.

That's good enough for me :)  My vote would be to continue to ignore
the L bit in 32-bit mode, then.  We should just remove the part that
implies qemu should enforce it from my patch commit message.

>
> Thanks,
>
> Paolo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]