From: Alexander Graf <agraf@suse.de>
To: Paolo Bonzini <pbonzini@redhat.com>, kvm-ppc@vger.kernel.org
Cc: kvm@vger.kernel.org
Subject: Re: [PATCH] KVM: PPC: HV: Remove generic instruction emulation
Date: Wed, 30 Jul 2014 18:57:05 +0000 [thread overview]
Message-ID: <53D94001.9090806@suse.de> (raw)
In-Reply-To: <53D91B97.9060408@redhat.com>
On 30.07.14 18:21, Paolo Bonzini wrote:
> Il 30/07/2014 15:27, Alexander Graf ha scritto:
>> Now that we have properly split load/store instruction emulation and generic
>> instruction emulation, we can move the generic one from kvm.ko to kvm-pr.ko
>> on book3s_64.
>>
>> This reduces the attack surface and amount of code loaded on HV KVM kernels.
> Can emulation races happen on HV KVM like you can have on x86?
> Basically one CPU writes to MMIO while the other patches instructions so
> that basically anything can end up in the hands of the emulator? On PPC
> it may even happen simply because of a missing icache invalidation, I
> think, since it doesn't support self-modifying code without explicit
> invalidation.
Yes, this is perfectly possible. As of my last patch set we will never
enter the generic emulator for HV KVM, so that race is moot (we just
inject a PROGRAM interrupt into the guest). With this patch even the
code to emulate these bits doesn't exist in the kernel anymore if you
don't modprobe kvm-pr.ko.
Alex
WARNING: multiple messages have this Message-ID (diff)
From: Alexander Graf <agraf@suse.de>
To: Paolo Bonzini <pbonzini@redhat.com>, kvm-ppc@vger.kernel.org
Cc: kvm@vger.kernel.org
Subject: Re: [PATCH] KVM: PPC: HV: Remove generic instruction emulation
Date: Wed, 30 Jul 2014 20:57:05 +0200 [thread overview]
Message-ID: <53D94001.9090806@suse.de> (raw)
In-Reply-To: <53D91B97.9060408@redhat.com>
On 30.07.14 18:21, Paolo Bonzini wrote:
> Il 30/07/2014 15:27, Alexander Graf ha scritto:
>> Now that we have properly split load/store instruction emulation and generic
>> instruction emulation, we can move the generic one from kvm.ko to kvm-pr.ko
>> on book3s_64.
>>
>> This reduces the attack surface and amount of code loaded on HV KVM kernels.
> Can emulation races happen on HV KVM like you can have on x86?
> Basically one CPU writes to MMIO while the other patches instructions so
> that basically anything can end up in the hands of the emulator? On PPC
> it may even happen simply because of a missing icache invalidation, I
> think, since it doesn't support self-modifying code without explicit
> invalidation.
Yes, this is perfectly possible. As of my last patch set we will never
enter the generic emulator for HV KVM, so that race is moot (we just
inject a PROGRAM interrupt into the guest). With this patch even the
code to emulate these bits doesn't exist in the kernel anymore if you
don't modprobe kvm-pr.ko.
Alex
next prev parent reply other threads:[~2014-07-30 18:57 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-30 13:27 [PATCH] KVM: PPC: HV: Remove generic instruction emulation Alexander Graf
2014-07-30 13:27 ` Alexander Graf
2014-07-30 16:21 ` Paolo Bonzini
2014-07-30 16:21 ` Paolo Bonzini
2014-07-30 18:57 ` Alexander Graf [this message]
2014-07-30 18:57 ` Alexander Graf
2014-07-30 19:47 ` Paolo Bonzini
2014-07-30 19:47 ` Paolo Bonzini
2014-07-30 19:48 ` Alexander Graf
2014-07-30 19:48 ` Alexander Graf
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=53D94001.9090806@suse.de \
--to=agraf@suse.de \
--cc=kvm-ppc@vger.kernel.org \
--cc=kvm@vger.kernel.org \
--cc=pbonzini@redhat.com \
/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.