On 2013-02-11 18:50, Gleb Natapov wrote:
> On Mon, Feb 11, 2013 at 07:40:38PM +0200, Gleb Natapov wrote:
>> On Mon, Feb 11, 2013 at 06:31:59PM +0100, Jan Kiszka wrote:
>>> On 2013-02-11 18:25, Gleb Natapov wrote:
>>>> On Mon, Feb 11, 2013 at 05:58:24PM +0100, Jan Kiszka wrote:
>>>>> On 2012-12-20 15:57, Gleb Natapov wrote:
>>>>>> According to Intel SDM Vol3 Section 5.5 "Privilege Levels" and 5.6
>>>>>> "Privilege Level Checking When Accessing Data Segments" RPL checking is
>>>>>> done during loading of a segment selector, not during data access. We
>>>>>> already do checking during segment selector loading, so drop the check
>>>>>> during data access. Checking RPL during data access triggers #GP if
>>>>>> after transition from real mode to protected mode RPL bits in a segment
>>>>>> selector are set.
>>>>>>
>>>>>> Signed-off-by: Gleb Natapov <gleb@xxxxxxxxxx>
>>>>>> ---
>>>>>> arch/x86/kvm/emulate.c | 7 +------
>>>>>> 1 file changed, 1 insertion(+), 6 deletions(-)
>>>>>>
>>>>>> diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
>>>>>> index c7547b3..a3d31e3 100644
>>>>>> --- a/arch/x86/kvm/emulate.c
>>>>>> +++ b/arch/x86/kvm/emulate.c
>>>>>> @@ -665,7 +665,7 @@ static int __linearize(struct x86_emulate_ctxt *ctxt,
>>>>>> ulong la;
>>>>>> u32 lim;
>>>>>> u16 sel;
>>>>>> - unsigned cpl, rpl;
>>>>>> + unsigned cpl;
>>>>>>
>>>>>> la = seg_base(ctxt, addr.seg) + addr.ea;
>>>>>> switch (ctxt->mode) {
>>>>>> @@ -699,11 +699,6 @@ static int __linearize(struct x86_emulate_ctxt *ctxt,
>>>>>> goto bad;
>>>>>> }
>>>>>> cpl = ctxt->ops->cpl(ctxt);
>>>>>> - if (ctxt->mode == X86EMUL_MODE_REAL)
>>>>>> - rpl = 0;
>>>>>> - else
>>>>>> - rpl = sel & 3;
>>>>>> - cpl = max(cpl, rpl);
>>>>>> if (!(desc.type & 8)) {
>>>>>> /* data segment */
>>>>>> if (cpl > desc.dpl)
>>>>>>
>>>>>
>>>>> I suppose this one is queued for 3.8 and stable already, right? We
>>>>> happen to hit the case reliably while booting an older SUSE guest on an
>>>>> AMD host.
>>>>>
>>>> The patch was in the middle of the pile of vmx real mode fixes. I had
>>>> no reports that it can be triggered on its own, so it was not queued
>>>> neither to 3.8 nor to stable. Is it a regression? If yes what version
>>>> the bug appears in?
>>>
>>> It is a regression of 618ff15 ("implement segment permission checks"),
>> Naturally :)
>>
>>> thus 3.0. We are running on such a 3.0.x host kernel (SLES11.2), and
>>> this issue only triggers on specific hosts with specific guest
>>> configurations. After no longer seeing it with kvm/next, I bisected the
>>> fix to this commit and instrumented it to ensure the case was actually hit.
>>>
>> I see. Too later to try and push it to 3.8 now, will queue for stable. Not
>> sure if 3.0 is still maintained by stable folks though.
>>
> And just after I wrote that 3.0.63 was announced.
Well, if you consider pushing it that far, an adapted version will be
needed. For us, it is not that important as we already have to patch kvm
down there due to missing f1c1da2bde (SVM: Keep intercepting task
switching with NPT enabled).
Jan
--
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
