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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2cb33bf8-f4f9-6a5b-ca72-d2dbcafc436d@redhat.com>
Date:   Fri, 10 Jul 2020 19:41:25 +0200
From:   Paolo Bonzini <pbonzini@...hat.com>
To:     Mohammed Gamal <mgamal@...hat.com>, kvm@...r.kernel.org
Cc:     linux-kernel@...r.kernel.org, vkuznets@...hat.com,
        sean.j.christopherson@...el.com, wanpengli@...cent.com,
        jmattson@...gle.com, joro@...tes.org
Subject: Re: [PATCH v3 3/9] KVM: x86: mmu: Add guest physical address check in
 translate_gpa()

On 10/07/20 17:48, Mohammed Gamal wrote:
> In case of running a guest with 4-level page tables on a 5-level page
> table host, it might happen that a guest might have a physical address
> with reserved bits set, but the host won't see that and trap it.
> 
> Hence, we need to check page faults' physical addresses against the guest's
> maximum physical memory and if it's exceeded, we need to add
> the PFERR_RSVD_MASK bits to the PF's error code.
> 
> Also make sure the error code isn't overwritten by the page table walker.
> 

New commit message:


    KVM: x86: mmu: Add guest physical address check in translate_gpa()
    
    Intel processors of various generations have supported 36, 39, 46 or 52
    bits for physical addresses.  Until IceLake introduced MAXPHYADDR==52,
    running on a machine with higher MAXPHYADDR than the guest more or less
    worked, because software that relied on reserved address bits (like KVM)
    generally used bit 51 as a marker and therefore the page faults where
    generated anyway.
    
    Unfortunately this is not true anymore if the host MAXPHYADDR is 52,
    and this can cause problems when migrating from a MAXPHYADDR<52
    machine to one with MAXPHYADDR==52.  Typically, the latter are machines
    that support 5-level page tables, so they can be identified easily from
    the LA57 CPUID bit.
    
    When that happens, the guest might have a physical address with reserved
    bits set, but the host won't see that and trap it.  Hence, we need
    to check page faults' physical addresses against the guest's maximum
    physical memory and if it's exceeded, we need to add the PFERR_RSVD_MASK
    bits to the page fault error code.
    
    This patch does this for the MMU's page walks.  The next patches will
    ensure that the correct exception and error code is produced whenever
    no host-reserved bits are set in page table entries.

Paolo

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ