linux-kernel - Re: [PATCH v2 17/18] KVM: x86: flush TLB separately from MMU reset

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <3863d7f1-a551-129d-d218-c4cce40041d3@redhat.com>
Date:   Mon, 21 Feb 2022 16:01:10 +0100
From:   Paolo Bonzini <pbonzini@...hat.com>
To:     Sean Christopherson <seanjc@...gle.com>
Cc:     linux-kernel@...r.kernel.org, kvm@...r.kernel.org
Subject: Re: [PATCH v2 17/18] KVM: x86: flush TLB separately from MMU reset

On 2/19/22 00:57, Sean Christopherson wrote:
> I appreciate the cleverness in changing only a single like, but I think both
> pieces warrant a mention.  How 'bout this, to squeak by with two lines?
> 
> 	/*
> 	 * Reset the MMU and flush the TLB if paging was enabled (INIT only, as
> 	 * CR0 is currently guaranteed to be '0' prior to RESET).  Unlike the

Let's just make it clearer:

          * On the standard CR0/CR4/EFER modification paths, there are several
          * complex conditions determining whether the MMU has to be reset and/or
          * which PCIDs have to be flushed.  However, CR0.WP and the paging-related
          * bits in CR4 and EFER are irrelevant if CR0.PG was '0'; and a reset+flush
          * is needed anyway if CR0.PG was '1' (which can only happen for INIT, as
          * CR0 will be '0' prior to RESET).  So we only need to check CR0.PG here.

Paolo