All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joerg Roedel <jroedel@suse.de>
To: speck@linutronix.de
Subject: [MODERATED] Re: ***UNCHECKED*** NX, nested virtualization and arch caps
Date: Wed, 16 Oct 2019 10:15:07 +0200	[thread overview]
Message-ID: <20191016081507.GD4695@suse.de> (raw)
In-Reply-To: <e057e3a4-6766-e606-797f-37108fa786f5@redhat.com>

Hi Paolo,

On Tue, Oct 15, 2019 at 11:45:14AM +0200, speck for Paolo Bonzini wrote:
> Right now, the NX patches are not advertising the
> ARCH_CAP_PSCHANGE_MC_NO bit to its guests (especially nested
> hypervisors).  This is despite KVM's shadow paging will ensure that the
> nested hypervisor's EPT pages are 4K in size.
> 
> This is because nx_huge_pages is writable.  Therefore, the value of the
> parameter could change from Y to N while a guest runs, and then the
> nested hypervisor would become vulnerable to the nested guest's bad
> behavior.
> 
> On the other hand, if the ITLB_MULTIHIT mitigation is disabled, then any
> guest is anyway vulnerable to other guests' shenanigans.  Therefore the
> nested hypervisor can just ignore ITLB_MULTIHIT altogether, even if it
> would then be vulnerable to L2's bad behavior.  And this means we can
> unconditionally advertise to nested hypervisors that the processor is
> not vulnerable.
> 
> Are there any issues with this reasoning?

I also think that any nested hypervisor can ignore the ITLB_MULTIHIT
bug, but for a different reason: The host also builds the nested EPT
table as a shadow of the guests EPT table, so it does the mitigation on
behalf of the nested hypervisor.

Regards,

	Joerg

  reply	other threads:[~2019-10-16  8:15 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-15  9:45 [MODERATED] NX, nested virtualization and arch caps Paolo Bonzini
2019-10-16  8:15 ` Joerg Roedel [this message]
2019-10-16  8:45   ` [MODERATED] Re: ***UNCHECKED*** " Joerg Roedel

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=20191016081507.GD4695@suse.de \
    --to=jroedel@suse.de \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.