1. 10 Mar, 2021 3 commits
  2. 09 Mar, 2021 3 commits
  3. 08 Mar, 2021 1 commit
  4. 06 Mar, 2021 1 commit
  5. 05 Mar, 2021 1 commit
  6. 04 Mar, 2021 5 commits
  7. 03 Mar, 2021 6 commits
  8. 02 Mar, 2021 6 commits
    • Jan Beulich's avatar
      x86/shadow: replace bogus return path in shadow_get_page_from_l1e() · 48349365
      Jan Beulich authored
      Prior to be640b18 ("x86: make get_page_from_l1e() return a proper
      error code") a positive return value did indicate an error. Said commit
      failed to adjust this return path, but luckily the only caller has
      always been inside a shadow_mode_refcounts() conditional.
      
      Subsequent changes caused 1 to end up at the default (error) label in
      the caller's switch() again, but the returning of 1 (== _PAGE_PRESENT)
      is still rather confusing here, and a latent risk.
      
      Convert to an ASSERT() instead, just in case any new caller would
      appear.
      Signed-off-by: default avatarJan Beulich <jbeulich@suse.com>
      Reviewed-by: default avatarAndrew Cooper <andrew.cooper3@citrix.com>
      Acked-by: default avatarTim Deegan <tim@xen.org>
      Release-Acked-by: default avatarIan Jackson <iwj@xenproject.org>
      48349365
    • Jan Beulich's avatar
      sched: fix build when NR_CPUS == 1 · 2de43f83
      Jan Beulich authored
      In this case the compiler is recognizing that no valid array indexes
      remain, and hence e.g. reports:
      
      core.c: In function 'cpu_schedule_up':
      core.c:2769:19: error: array subscript 1 is above array bounds
      of 'struct vcpu *[1]' [-Werror=array-bounds]
       2769 |     if ( idle_vcpu[cpu] == NULL )
            |          ~~~~~~~~~^~~~~
      Reported-by: default avatarConnor Davis <connojdavis@gmail.com>
      Signed-off-by: default avatarJan Beulich <jbeulich@suse.com>
      Reviewed-by: default avatarDario Faggioli <dfaggioli@suse.com>
      Release-Acked-by: default avatarIan Jackson <iwj@xenproject.org>
      2de43f83
    • Julien Grall's avatar
      xen/iommu: x86: Clear the root page-table before freeing the page-tables · 9bd9695a
      Julien Grall authored
      The new per-domain IOMMU page-table allocator will now free the
      page-tables when domain's resources are relinquished. However, the
      per-domain IOMMU structure will still contain a dangling pointer to
      the root page-table.
      
      Xen may access the IOMMU page-tables afterwards at least in the case of
      PV domain:
      
      (XEN) Xen call trace:
      (XEN)    [<ffff82d04025b4b2>] R iommu.c#addr_to_dma_page_maddr+0x12e/0x1d8
      (XEN)    [<ffff82d04025b695>] F iommu.c#intel_iommu_unmap_page+0x5d/0xf8
      (XEN)    [<ffff82d0402695f3>] F iommu_unmap+0x9c/0x129
      (XEN)    [<ffff82d0402696a6>] F iommu_legacy_unmap+0x26/0x63
      (XEN)    [<ffff82d04033c5c7>] F mm.c#cleanup_page_mappings+0x139/0x144
      (XEN)    [<ffff82d04033c61d>] F put_page+0x4b/0xb3
      (XEN)    [<ffff82d04033c87f>] F put_page_from_l1e+0x136/0x13b
      (XEN)    [<ffff82d04033cada>] F devalidate_page+0x256/0x8dc
      (XEN)    [<ffff82d04033d396>] F mm.c#_put_page_type+0x236/0x47e
      (XEN)    [<ffff82d04033d64d>] F mm.c#put_pt_page+0x6f/0x80
      (XEN)    [<ffff82d04033d8d6>] F mm.c#put_page_from_l2e+0x8a/0xcf
      (XEN)    [<ffff82d04033cc27>] F devalidate_page+0x3a3/0x8dc
      (XEN)    [<ffff82d04033d396>] F mm.c#_put_page_type+0x236/0x47e
      (XEN)    [<ffff82d04033d64d>] F mm.c#put_pt_page+0x6f/0x80
      (XEN)    [<ffff82d04033d807>] F mm.c#put_page_from_l3e+0x8a/0xcf
      (XEN)    [<ffff82d04033cdf0>] F devalidate_page+0x56c/0x8dc
      (XEN)    [<ffff82d04033d396>] F mm.c#_put_page_type+0x236/0x47e
      (XEN)    [<ffff82d04033d64d>] F mm.c#put_pt_page+0x6f/0x80
      (XEN)    [<ffff82d04033d6c7>] F mm.c#put_page_from_l4e+0x69/0x6d
      (XEN)    [<ffff82d04033cf24>] F devalidate_page+0x6a0/0x8dc
      (XEN)    [<ffff82d04033d396>] F mm.c#_put_page_type+0x236/0x47e
      (XEN)    [<ffff82d04033d92e>] F put_page_type_preemptible+0x13/0x15
      (XEN)    [<ffff82d04032598a>] F domain.c#relinquish_memory+0x1ff/0x4e9
      (XEN)    [<ffff82d0403295f2>] F domain_relinquish_resources+0x2b6/0x36a
      (XEN)    [<ffff82d040205cdf>] F domain_kill+0xb8/0x141
      (XEN)    [<ffff82d040236cac>] F do_domctl+0xb6f/0x18e5
      (XEN)    [<ffff82d04031d098>] F pv_hypercall+0x2f0/0x55f
      (XEN)    [<ffff82d04039b432>] F lstar_enter+0x112/0x120
      
      This will result to a use after-free and possibly an host crash or
      memory corruption.
      
      It would not be possible to free the page-tables further down in
      domain_relinquish_resources() because cleanup_page_mappings() will only
      be called when the last reference on the page dropped. This may happen
      much later if another domain still hold a reference.
      
      After all the PCI devices have been de-assigned, nobody should use the
      IOMMU page-tables and it is therefore pointless to try to modify them.
      
      So we can simply clear any reference to the root page-table in the
      per-domain IOMMU structure. This requires to introduce a new callback of
      the method will depend on the IOMMU driver used.
      
      Take the opportunity to add an ASSERT() in arch_iommu_domain_destroy()
      to check if we freed all the IOMMU page tables.
      
      Fixes: 3eef6d07 ("x86/iommu: convert VT-d code to use new page table allocator")
      Signed-off-by: default avatarJulien Grall <jgrall@amazon.com>
      Reviewed-by: default avatarJan Beulich <jbeulich@suse.com>
      Reviewed-by: default avatarKevin Tian <kevin.tian@intel.com>
      Release-Acked-by: default avatarIan Jackson <iwj@xenproject.org>
      9bd9695a
    • Julien Grall's avatar
      xen/x86: iommu: Ignore IOMMU mapping requests when a domain is dying · 1ef48c82
      Julien Grall authored
      The new x86 IOMMU page-tables allocator will release the pages when
      relinquishing the domain resources. However, this is not sufficient
      when the domain is dying because nothing prevents page-table to be
      allocated.
      
      As the domain is dying, it is not necessary to continue to modify the
      IOMMU page-tables as they are going to be destroyed soon.
      
      At the moment, page-table allocates will only happen when iommu_map().
      So after this change there will be no more page-table allocation
      happening because we don't use superpage mappings yet when not sharing
      page tables.
      
      In order to observe d->is_dying correctly, we need to rely on per-arch
      locking, so the check to ignore IOMMU mapping is added on the per-driver
      map_page() callback.
      
      Fixes: 15bc9a1e ("x86/iommu: add common page-table allocator")
      Signed-off-by: default avatarJulien Grall <jgrall@amazon.com>
      Reviewed-by: default avatarJan Beulich <jbeulich@suse.com>
      Reviewed-by: default avatarKevin Tian <kevin.tian@intel.com>
      Release-Acked-by: default avatarIan Jackson <iwj@xenproject.org>
      1ef48c82
    • Julien Grall's avatar
      xen/iommu: x86: Don't try to free page tables is the IOMMU is not enabled · f4cf483e
      Julien Grall authored
      When using CONFIG_BIGMEM=y, the page_list cannot be accessed whilst it
      is is unitialized. However, iommu_free_pgtables() will be called even if
      the domain is not using an IOMMU.
      
      Consequently, Xen will try to go through the page list and deference a
      NULL pointer.
      
      Bail out early if the domain is not using an IOMMU.
      
      Fixes: 15bc9a1e ("x86/iommu: add common page-table allocator")
      Signed-off-by: default avatarJulien Grall <jgrall@amazon.com>
      Reviewed-by: default avatarJan Beulich <jbeulich@suse.com>
      Release-Acked-by: default avatarIan Jackson <iwj@xenproject.org>
      f4cf483e
    • Julien Grall's avatar
      tools/xenstored: Avoid dereferencing a NULL pointer if LiveUpdate is failing · 29fae90b
      Julien Grall authored
      In case of failure in do_lu_start(), XenStored will first free lu_start
      and then try to dereference it.
      
      This will result to a NULL dereference as the destruction callback will
      set lu_start to NULL.
      
      The crash can be avoided by freeing lu_start *after* the reply has been
      set.
      
      Fixes: af216a99 ("tools/xenstore: add the basic framework for doing the live update")
      Signed-off-by: default avatarJulien Grall <jgrall@amazon.com>
      Reviewed-by: default avatarJuergen Gross <jgross@suse.com>
      Release-Acked-by: default avatarIan Jackson <iwj@xenproject.org>
      29fae90b
  9. 01 Mar, 2021 6 commits
  10. 26 Feb, 2021 8 commits