[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-changelog] [xen staging] x86/mm: Don't perform flush after failing to update a guests L1e



commit 6c8d50288722672ecc8e19b0741a31b521d01706
Author:     Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
AuthorDate: Tue Nov 20 14:58:41 2018 +0100
Commit:     Jan Beulich <jbeulich@xxxxxxxx>
CommitDate: Tue Nov 20 14:58:41 2018 +0100

    x86/mm: Don't perform flush after failing to update a guests L1e
    
    If the L1e update hasn't occured, the flush cannot do anything useful.  This
    skips the potentially expensive vcpumask_to_pcpumask() conversion, and
    broadcast TLB shootdown.
    
    More importantly however, we might be in the error path due to a bad va
    parameter from the guest, and this should not propagate into the TLB 
flushing
    logic.  The INVPCID instruction for example raises #GP for a non-canonical
    address.
    
    This is XSA-279.
    
    Reported-by: Matthew Daley <mattd@xxxxxxxxxxx>
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
---
 xen/arch/x86/mm.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 55f1cb182e..1545baf20b 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4152,6 +4152,14 @@ static int __do_update_va_mapping(
     if ( pl1e )
         unmap_domain_page(pl1e);
 
+    /*
+     * Any error at this point means that we haven't change the L1e.  Skip the
+     * flush, as it won't do anything useful.  Furthermore, va is guest
+     * controlled and not necesserily audited by this point.
+     */
+    if ( rc )
+        return rc;
+
     switch ( flags & UVMF_FLUSHTYPE_MASK )
     {
     case UVMF_TLB_FLUSH:
--
generated by git-patchbot for /home/xen/git/xen.git#staging

_______________________________________________
Xen-changelog mailing list
Xen-changelog@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/xen-changelog

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.