All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Bandan Das <bsd@redhat.com>, kvm <kvm@vger.kernel.org>
Subject: Re: x86: Don't report guest userspace emulation error to userspace, why ?
Date: Thu, 10 Dec 2015 10:12:41 +0100	[thread overview]
Message-ID: <56694209.5050800@redhat.com> (raw)
In-Reply-To: <jpg6107gtaf.fsf@linux.bootlegged.copy>



On 09/12/2015 23:18, Bandan Das wrote:
> Commit a2b9e6c1a35afcc09:
> 
>     KVM: x86: Don't report guest userspace emulation error to userspace
>     
>     Commit fc3a9157d314 ("KVM: X86: Don't report L2 emulation failures to
>     user-space") disabled the reporting of L2 (nested guest) emulation failures to
>     userspace due to race-condition between a vmexit and the instruction emulator.
>     The same rational applies also to userspace applications that are permitted by
>     the guest OS to access MMIO area or perform PIO.
>     
>     This patch extends the current behavior - of injecting a #UD instead of
>     reporting it to userspace - also for guest userspace code.
>     
> I searched the archives but failed in finding anything. Can someone please
> explain why this is needed ? Or, why not let userspace decide what to do based
> on the cpl, whether to continue execution or kill the guest ? Is the assumption
> here that this is what userspace always wants ?

Not what userspace always wants, but what the guest kernel always wants.

Allowing userspace to stop the guest with an emulation failure is a
possible denial of service, similar to L2 stopping L1 with an emulation
failure.

Paolo

  reply	other threads:[~2015-12-10  9:12 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-09 22:18 x86: Don't report guest userspace emulation error to userspace, why ? Bandan Das
2015-12-10  9:12 ` Paolo Bonzini [this message]
2015-12-10 17:58   ` Bandan Das
2015-12-10 17:59     ` Paolo Bonzini
2015-12-10 18:36       ` Bandan Das
2015-12-10 20:20         ` Paolo Bonzini
2015-12-10 20:35           ` Bandan Das

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=56694209.5050800@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=bsd@redhat.com \
    --cc=kvm@vger.kernel.org \
    /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.