From: Paolo Bonzini <pbonzini@redhat.com>
To: speck@linutronix.de
Subject: [MODERATED] Re: [PATCH v2.1 5/6] [PATCH v2.1 5/6] Patch #5
Date: Thu, 21 Jun 2018 19:29:26 +0200 [thread overview]
Message-ID: <349b96d0-27e3-77c1-63cf-f6f79b133c8e@redhat.com> (raw)
In-Reply-To: <20180621140454.GA2293@char.US.ORACLE.com>
[-- Attachment #1: Type: text/plain, Size: 2651 bytes --]
On 21/06/2018 16:04, speck for Konrad Rzeszutek Wilk wrote:
>> - They trigger the emulator, which could be a good target for
>> other speculative execution-based threats,
>> - or the MMU, which can bring host page tables in the L1 cache.
>> - In addition, executing userspace or another process will trigger a flush.
> What about softirqs? Won't that happen on every VMEXIT?
Not on every, but this is covered. The code has a more verbose comment
* - anything that can run code outside KVM (external interrupt,
* which can run interrupt handlers or irqs; or the sched_in
* preempt notifier)
> And how about
> interrupts? They can happen too, any way to figure out whether an interrupt
> happend between VMEXIT -> VMENTER?
Nope. A kernel-only vmexit (of the kind that isn't considered
"unconfined" anyway) is less than a microsecond so it's not that likely,
but it is going to happen if the guest does a busy cpuid loop and uses
rdtsc to detect outliers.
We could add a generation count for softirqs, and possibly blacklist HLT
vmexits in case it does kvm->idle->kvm with no actual context switch.
> Also would it make sense to flip this around - that is everything is considered
> a blacklist (aka always flush), except those routines which we believe
> are OK and hence can be whitelisted?
I did this in v1, but in the end when reviewing the list I ended up
putting everything on the whitelist.
vmexit is a very fast path. This means that 1) it's unlikely to do
expensive things 2) you don't really want to add overhead there. I'm
okay with blacklisting more nested virt operations (vmclear, vmptrld);
that would hit nested VMware Workstation and possibly VirtualBox pretty
badly, but honestly who cares.
> And then what about the situation where say in a month somebody fixes a bug
> or adds a new feature that brings in the host page table (alloc_page?)
> and now we have to move it from whitelist to blacklist - there is not much
> of an automatic way to detect this I think?
>
> Or maybe there is? What are some of the calls that KVM can make that would
> bring in the host page tables? I am assuming any call that hits 'page_alloc'
> or 'kzalloc', 'vzalloc' or such? But others?
That's what I did in this patch.
> I vaguely recall folks saying that they tried the "trigger IPI on VMEXIT" - was
> there any performance metrix compared to say having SMT disabled/enabled?
> And are there any patches for this floating around that have been ported against
> upstream kernel?
No, they were just too ugly, and the benefit of hyperthreading is debatable.
Paolo
prev parent reply other threads:[~2018-06-21 17:29 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-20 20:43 [MODERATED] [PATCH v2.1 5/6] [PATCH v2.1 5/6] Patch #5 konrad.wilk
2018-06-20 20:57 ` [MODERATED] " Konrad Rzeszutek Wilk
2018-06-21 3:17 ` Konrad Rzeszutek Wilk
2018-06-21 14:04 ` Konrad Rzeszutek Wilk
2018-06-21 17:29 ` Paolo Bonzini [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=349b96d0-27e3-77c1-63cf-f6f79b133c8e@redhat.com \
--to=pbonzini@redhat.com \
--cc=speck@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).