From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 58480C43334 for ; Thu, 21 Jul 2022 14:57:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231200AbiGUO5P (ORCPT ); Thu, 21 Jul 2022 10:57:15 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44018 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232441AbiGUO5L (ORCPT ); Thu, 21 Jul 2022 10:57:11 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id A613A1F2F5 for ; Thu, 21 Jul 2022 07:57:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1658415429; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=FtBAxFvMFDzgwHndzmBu4PFBZ+QVw2pSEVvuBlD9/k8=; b=BqCWGctikk5zy6sYbqQRXkgZ/lunPvr8GPyOM5ZJkmxh8SaL6WMHuj/4Wi57bP6FVrWKt8 InjcQxduIXJM29O4t6gsNaAJSKehlc8RTbZ2UJzh4fwIaK8j+Ilb1XpPJgYZ/YXYijQPi8 Ht1edbkiEEZyOC8Wh8M+18I3ouaY8A8= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-59-Gn6dFRFKMj6x1PROaP9Jag-1; Thu, 21 Jul 2022 10:57:08 -0400 X-MC-Unique: Gn6dFRFKMj6x1PROaP9Jag-1 Received: from smtp.corp.redhat.com (int-mx09.intmail.prod.int.rdu2.redhat.com [10.11.54.9]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 83FD31019C96; Thu, 21 Jul 2022 14:57:07 +0000 (UTC) Received: from starship (unknown [10.40.192.46]) by smtp.corp.redhat.com (Postfix) with ESMTP id 3B445492CA5; Thu, 21 Jul 2022 14:57:03 +0000 (UTC) Message-ID: Subject: Re: [PATCH v2 05/11] KVM: x86: emulator: update the emulation mode after CR0 write From: Maxim Levitsky To: Sean Christopherson Cc: kvm@vger.kernel.org, x86@kernel.org, Kees Cook , Dave Hansen , linux-kernel@vger.kernel.org, "H. Peter Anvin" , Borislav Petkov , Joerg Roedel , Ingo Molnar , Paolo Bonzini , Thomas Gleixner , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson Date: Thu, 21 Jul 2022 17:57:02 +0300 In-Reply-To: References: <20220621150902.46126-1-mlevitsk@redhat.com> <20220621150902.46126-6-mlevitsk@redhat.com> <532c71cbca049004bd6860508fdc056ae118ab1f.camel@redhat.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.36.5 (3.36.5-2.fc32) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.85 on 10.11.54.9 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2022-07-21 at 14:11 +0000, Sean Christopherson wrote: > On Thu, Jul 21, 2022, Maxim Levitsky wrote: > > On Wed, 2022-07-20 at 23:50 +0000, Sean Christopherson wrote: > > > On Tue, Jun 21, 2022, Maxim Levitsky wrote: > > > > CR0.PE toggles real/protected mode, thus its update > > > > should update the emulation mode. > > > > > > > > This is likely a benign bug because there is no writeback > > > > of state, other than the RIP increment, and when toggling > > > > CR0.PE, the CPU has to execute code from a very low memory address. > > > > > > > > Signed-off-by: Maxim Levitsky > > > > --- > > > > arch/x86/kvm/emulate.c | 13 ++++++++++++- > > > > 1 file changed, 12 insertions(+), 1 deletion(-) > > > > > > > > diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c > > > > index 6f4632babc4cd8..002687d17f9364 100644 > > > > --- a/arch/x86/kvm/emulate.c > > > > +++ b/arch/x86/kvm/emulate.c > > > > @@ -3659,11 +3659,22 @@ static int em_movbe(struct x86_emulate_ctxt *ctxt) > > > > > > > > static int em_cr_write(struct x86_emulate_ctxt *ctxt) > > > > { > > > > - if (ctxt->ops->set_cr(ctxt, ctxt->modrm_reg, ctxt->src.val)) > > > > + int cr_num = ctxt->modrm_reg; > > > > + int r; > > > > + > > > > + if (ctxt->ops->set_cr(ctxt, cr_num, ctxt->src.val)) > > > > return emulate_gp(ctxt, 0); > > > > > > > > /* Disable writeback. */ > > > > ctxt->dst.type = OP_NONE; > > > > + > > > > + if (cr_num == 0) { > > > > + /* CR0 write might have updated CR0.PE */ > > > > > > Or toggled CR0.PG. > > > > I thought about it but paging actually does not affect the CPU mode. > > Toggling CR0.PG when EFER.LME=1 (and CR4.PAE=1) switches the CPU in and out of > long mode. That's why I mentioned the EFER.LMA thing below. It's also notable > in that the only reason we don't have to handle CR4 here is because clearing > CR4.PAE while long is active causes a #GP. I had a distinct feeling that this is related to LMA/LME which I always learn and then forget Now I do, and I wrote a short summary for myself to refresh my memory when I forget about this again :-) I'll update the comment again in v3. Thanks a lot, Best regards, Maxim Levitsky > > > E.g if you are in protected mode, instructions execute the same regardless > > if you have paging or not. > > > > (There are probably some exceptions but you understand what I mean). > > > > Best regards, > > Maxim Levitsky > > > > > It's probably also worth noting that ->set_cr() handles side > > > effects to other registers, e.g. the lack of an EFER.LMA update makes this look > > > suspicious at first glance.