From: Laszlo Ersek <lersek@redhat.com>
To: "Radim Krčmář" <rkrcmar@redhat.com>
Cc: kvm@vger.kernel.org, Paolo Bonzini <pbonzini@redhat.com>,
Jordan Justen <jordan.l.justen@intel.com>,
Michael Kinney <michael.d.kinney@intel.com>,
stable@vger.kernel.org
Subject: Re: [PATCH] KVM: x86: fix RSM into 64-bit protected mode, round 2
Date: Mon, 26 Oct 2015 16:43:25 +0100 [thread overview]
Message-ID: <562E4A1D.7000900@redhat.com> (raw)
In-Reply-To: <20151026153715.GA31158@potion.brq.redhat.com>
On 10/26/15 16:37, Radim Krčmář wrote:
> 2015-10-23 23:43+0200, Laszlo Ersek:
>> Commit b10d92a54dac ("KVM: x86: fix RSM into 64-bit protected mode")
>> reordered the rsm_load_seg_64() and rsm_enter_protected_mode() calls,
>> relative to each other. The argument that said commit made was correct,
>> however putting rsm_enter_protected_mode() first whole-sale violated the
>> following (correct) invariant from em_rsm():
>>
>> * Get back to real mode, to prepare a safe state in which to load
>> * CR0/CR3/CR4/EFER. Also this will ensure that addresses passed
>> * to read_std/write_std are not virtual.
>
> Nice catch.
>
>> Namely, rsm_enter_protected_mode() may re-enable paging, *after* which
>>
>> rsm_load_seg_64()
>> GET_SMSTATE()
>> read_std()
>>
>> will try to interpret the (smbase + offset) address as a virtual one. This
>> will result in unexpected page faults being injected to the guest in
>> response to the RSM instruction.
>
> I think this is a good time to introduce the read_phys helper, which we
> wanted to avoid with that assumption.
>
>> Split rsm_load_seg_64() in two parts:
>>
>> - The first part, rsm_stash_seg_64(), shall call GET_SMSTATE() while in
>> real mode, and save the relevant state off SMRAM into an array local to
>> rsm_load_state_64().
>>
>> - The second part, rsm_load_seg_64(), shall occur after entering protected
>> mode, but the segment details shall come from the local array, not the
>> guest's SMRAM.
>>
>> Fixes: b10d92a54dac25a6152f1aa1ffc95c12908035ce
>> Cc: Paolo Bonzini <pbonzini@redhat.com>
>> Cc: Radim Krčmář <rkrcmar@redhat.com>
>> Cc: Jordan Justen <jordan.l.justen@intel.com>
>> Cc: Michael Kinney <michael.d.kinney@intel.com>
>> Cc: stable@vger.kernel.org
>> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
>> ---
>
> The code would be cleaner if we had a different approach, but this works
> too and is safer for stable. In case you prefer to leave the rewrite for
> a future victim,
It's hard to express how much I prefer that.
>
> Reviewed-by: Radim Krčmář <rkrcmar@redhat.com>
>
Thank you!
Laszlo
next prev parent reply other threads:[~2015-10-26 15:43 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-23 21:43 [PATCH] KVM: x86: fix RSM into 64-bit protected mode, round 2 Laszlo Ersek
2015-10-23 21:43 ` Laszlo Ersek
2015-10-26 15:37 ` Radim Krčmář
2015-10-26 15:43 ` Laszlo Ersek [this message]
2015-10-26 16:32 ` Paolo Bonzini
2015-10-30 15:40 ` Radim Krčmář
2015-10-31 17:09 ` Laszlo Ersek
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=562E4A1D.7000900@redhat.com \
--to=lersek@redhat.com \
--cc=jordan.l.justen@intel.com \
--cc=kvm@vger.kernel.org \
--cc=michael.d.kinney@intel.com \
--cc=pbonzini@redhat.com \
--cc=rkrcmar@redhat.com \
--cc=stable@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.