x86/pv: Fix ABAC cmpxchg() race in _get_page_type()

x86/pv: Fix ABAC cmpxchg() race in _get_page_type()

_get_page_type() suffers from a race condition where it incorrectly assumes
that because 'x' was read and a subsequent a cmpxchg() succeeds, the type
cannot have changed in-between.  Consider:

CPU A:
  1. Creates an L2e referencing pg
     `-> _get_page_type(pg, PGT_l1_page_table), sees count 0, type PGT_writable_page
  2.     Issues flush_tlb_mask()
CPU B:
  3. Creates a writeable mapping of pg
     `-> _get_page_type(pg, PGT_writable_page), count increases to 1
  4. Writes into new mapping, creating a TLB entry for pg
  5. Removes the writeable mapping of pg
     `-> _put_page_type(pg), count goes back down to 0
CPU A:
  7.     Issues cmpxchg(), setting count 1, type PGT_l1_page_table

CPU B now has a writeable mapping to pg, which Xen believes is a pagetable and
suitably protected (i.e. read-only).  The TLB flush in step 2 must be deferred
until after the guest is prohibited from creating new writeable mappings,
which is after step 7.

Defer all safety actions until after the cmpxchg() has successfully taken the
intended typeref, because that is what prevents concurrent users from using
the old type.

Also remove the early validation for writeable and shared pages.  This removes
race conditions where one half of a parallel mapping attempt can return
successfully before:
 * The IOMMU pagetables are in sync with the new page type
 * Writeable mappings to shared pages have been torn down

This is part of XSA-401 / CVE-2022-26362.

Reported-by: Jann Horn <jannh@google.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: George Dunlap <george.dunlap@citrix.com>