linux-kernel - Re: [PATCH 07/23] KVM: MMU: remove kvm_mmu_calc_root_page

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: <1e8c38eb-d66a-60e7-9432-eb70e7ec1dd4@redhat.com>
Date:   Thu, 10 Feb 2022 10:52:03 +0100
From:   Paolo Bonzini <pbonzini@...hat.com>
To:     Sean Christopherson <seanjc@...gle.com>
Cc:     linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
        dmatlack@...gle.com, vkuznets@...hat.com
Subject: Re: [PATCH 07/23] KVM: MMU: remove kvm_mmu_calc_root_page_role

On 2/10/22 01:47, Sean Christopherson wrote:
> The nested mess is likely easily solved, I don't see any obvious issue with swapping
> the order.  But I still don't love the subtlety.  I do like shaving cycles, just
> not the subtlety...

Not so easily, but it's doable and it's essentially what I did in the 
other series (the one that reworks the root cache).

Quick spoiler: there's a complicated dependency between the _old_ values 
in kvm_mmu and the root cache, so that the root cache code currently 
needs both the old MMU state (especially shadow_root_level/root_level) 
and the new role.

kvm_mmu_reset_context does the expensive kvm_mmu_unload to cop out of 
having to know in advance the new role; the crux of the other series is 
to remove that need, so that kvm_mmu_reset_context does not have to cop 
out anymore.

> If we do rework things to have kvm_mmu_new_pgd() pull the role from the mmu, then
> we should first add a long overdue audit/warn that KVM never runs with a mmu_role
> that isn't consistent with respect to its root SP's role.

There's a much cheaper check that can be done to enforce the invariant 
that kvm_mmu_new_pgd must follow kvm_init_mmu: kvm_init_mmu sets a 
not_ready flag, kvm_mmu_new_pgd clears it, and kvm_mmu_reload screams if 
it sees not_ready == 1.

Paolo