[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87lg6e5h89.fsf@ashishki-desk.ger.corp.intel.com>
Date: Wed, 31 Oct 2018 16:21:58 +0200
From: Alexander Shishkin <alexander.shishkin@...ux.intel.com>
To: Paolo Bonzini <pbonzini@...hat.com>,
Luwei Kang <luwei.kang@...el.com>, kvm@...r.kernel.org,
x86@...nel.org
Cc: tglx@...utronix.de, mingo@...hat.com, bp@...en8.de, hpa@...or.com,
rkrcmar@...hat.com, joro@...tes.org, songliubraving@...com,
peterz@...radead.org, kstewart@...uxfoundation.org,
gregkh@...uxfoundation.org, thomas.lendacky@....com,
konrad.wilk@...cle.com, mattst88@...il.com,
Janakarajan.Natarajan@....com, dwmw@...zon.co.uk,
jpoimboe@...hat.com, marcorr@...gle.com, ubizjak@...il.com,
sean.j.christopherson@...el.com, jmattson@...gle.com,
linux-kernel@...r.kernel.org,
Chao Peng <chao.p.peng@...ux.intel.com>
Subject: Re: [PATCH v13 08/12] KVM: x86: Add Intel PT context switch for each vcpu
Paolo Bonzini <pbonzini@...hat.com> writes:
> On 31/10/2018 12:38, Alexander Shishkin wrote:
>>> There is no standard way to tell the guest that the host overrode its
>>> choice to use PT. However, the host will get a PGD/PGE packet around
>>> vmentry and vmexit, so there _will_ be an indication that the guest
>>> owned the MSRs for that period of time.
>>
>> Not if they are not tracing the kernel.
>
> If they are not tracing the kernel why should they be tracing the guest
> at all?
To trace the guest userspace, perhaps?
>>> If PT context switching is enabled with the module parameter, we could
>>> also reject creation of events with the attribute set. However that
>>> won't help if the event is created before KVM is even loaded.
>>
>> In that case, modprobe kvm should fail.
>
> Does that mean that an unprivileged user can effectively DoS
> virtualization for everyone on the machine? (Honest question).
Would the leave-PT-to-the-host still be allowed? Would ignoring the
module parameter in that case and falling back to this mode still be
fine?
I'm not really the one to brainstorm solutions here. There are
possibilities of solving this, and the current patchset does not even
begin to acknowledge the existence of the problem, which is what my ACK
depends on.
Regards,
--
Alex
Powered by blists - more mailing lists