linux-kernel - Re: [RFC] KVM: SVM: do not drop VMCB CPL to 0 if SS is not present

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 30 May 2017 18:31:20 +0200
From:   Gi-Oh Kim <gi-oh.kim@...fitbricks.com>
To:     Paolo Bonzini <pbonzini@...hat.com>
Cc:     Roman Penyaev <roman.penyaev@...fitbricks.com>,
        Mikhail Sennikovskii <mikhail.sennikovskii@...fitbricks.com>,
        Gleb Natapov <gleb@...nel.org>, kvm@...r.kernel.org,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Andy Lutomirski <luto@...capital.net>
Subject: Re: [RFC] KVM: SVM: do not drop VMCB CPL to 0 if SS is not present

Hi,

I found a code to set unusable flag of segment register incorrectly.
https://lkml.org/lkml/2017/5/30/459
I guess above patch and current discussion could be related.

I guess following sequence could happen.
1. svm_get_segment() sets var->unusable of Stack Segment incorrectly
2. svm_set_segment() clears both of s->attrib and svm->vmcb->save.cpl.

Is it possible scenario?


On Tue, May 30, 2017 at 6:05 PM, Paolo Bonzini <pbonzini@...hat.com> wrote:
>
>
> On 30/05/2017 17:58, Roman Penyaev wrote:
>> Indeed, what is left is eventually take it from SS.RPL. J.
>
> Ahah! :)  But I only suggested that in specific cases.
>
>> But jokes aside,  with your last patch you seems fixed a race problem
>> when "CS.RPL is not equal to the CPL in the few instructions between
>> setting CR0.PE and reloading CS".
>
> Yes, exactly.  The symptom was a crash (triple fault) when you kept
> interrupting with "info cpus" a guest that repeatedly went to protected
> mode and back to real mode.
>
>> We will have CPL in var->dpl, and it seems ok.  All we need is not
>> to lose it on the way kernel->userspace->kernel.
>
> You're right.  So what do you think of the other suggestion (svm.c
> doesn't clear attributes for unusable registers, QEMU only clears P for
> unusable registers)?
>
> Thanks,
>
> Paolo



-- 
Best regards,
Gi-Oh Kim
TEL: 0176 2697 8962