1. 18 Nov, 2020 11 commits
  2. 11 Nov, 2020 3 commits
  3. 10 Nov, 2020 7 commits
    • Julien Grall's avatar
      xen/arm: Always trap AMU system registers · 628e1bec
      Julien Grall authored
      
      
      The Activity Monitors Unit (AMU) has been introduced by ARMv8.4. It is
      considered to be unsafe to be expose to guests as they might expose
      information about code executed by other guests or the host.
      
      Arm provided a way to trap all the AMU system registers by setting
      CPTR_EL2.TAM to 1.
      
      Unfortunately, on older revision of the specification, the bit 30 (now
      CPTR_EL1.TAM) was RES0. Because of that, Xen is setting it to 0 and
      therefore the system registers would be exposed to the guest when it is
      run on processors with AMU.
      
      As the bit is mark as UNKNOWN at boot in Armv8.4, the only safe solution
      for us is to always set CPTR_EL1.TAM to 1.
      
      Guest trying to access the AMU system registers will now receive an
      undefined instruction. Unfortunately, this means that even well-behaved
      guest may fail to boot because we don't sanitize the ID registers.
      
      This is a known issues with other Armv8.0+ features (e.g. SVE, Pointer
      Auth). This will taken care separately.
      
      This is part of XSA-351 (or XSA-93 re-born).
      Signed-off-by: default avatarJulien Grall <jgrall@amazon.com>
      Reviewed-by: default avatarAndre Przywara <andre.przywara@arm.com>
      Reviewed-by: Stefano Stabellini's avatarStefano Stabellini <sstabellini@kernel.org>
      Reviewed-by: Bertrand Marquis's avatarBertrand Marquis <bertrand.marquis@arm.com>
      628e1bec
    • Jan Beulich's avatar
      x86/CPUID: also check leaf 7 max subleaf to be compatible · e6e85b66
      Jan Beulich authored
      
      
      Just like is done for basic and extended major leaves.
      Signed-off-by: Jan Beulich's avatarJan Beulich <jbeulich@suse.com>
      Acked-by: Andrew Cooper's avatarAndrew Cooper <andrew.cooper3@citrix.com>
      e6e85b66
    • Jan Beulich's avatar
      x86/CPUID: suppress IOMMU related hypervisor leaf data · f5cfa098
      Jan Beulich authored
      
      
      Now that the IOMMU for guests can't be enabled "on demand" anymore,
      there's also no reason to expose the related CPUID bit "just in case".
      Signed-off-by: Jan Beulich's avatarJan Beulich <jbeulich@suse.com>
      Acked-by: Andrew Cooper's avatarAndrew Cooper <andrew.cooper3@citrix.com>
      f5cfa098
    • Jan Beulich's avatar
      x86/CPUID: don't use UB shift when library is built as 32-bit · db1a9fdd
      Jan Beulich authored
      
      
      At least the insn emulator test harness will continue to be buildable
      (and ought to continue to be usable) also as a 32-bit binary. (Right now
      the CPU policy test harness is, too, but there it may be less relevant
      to keep it functional, just like e.g. we don't support fuzzing the insn
      emulator in 32-bit mode.) Hence the library code needs to cope with
      this.
      Signed-off-by: Jan Beulich's avatarJan Beulich <jbeulich@suse.com>
      Acked-by: Andrew Cooper's avatarAndrew Cooper <andrew.cooper3@citrix.com>
      db1a9fdd
    • Juergen Gross's avatar
      xen/evtchn: revert 52e1fc47 · b5ad37f8
      Juergen Gross authored
      With the event channel lock no longer disabling interrupts commit
      52e1fc47
      
       ("evtchn/Flask: pre-allocate node on send path") can
      be reverted again.
      Signed-off-by: Juergen Gross's avatarJuergen Gross <jgross@suse.com>
      Acked-by: Jan Beulich's avatarJan Beulich <jbeulich@suse.com>
      b5ad37f8
    • Juergen Gross's avatar
      xen/evtchn: rework per event channel lock · 5f2df45e
      Juergen Gross authored
      Currently the lock for a single event channel needs to be taken with
      interrupts off, which causes deadlocks in some cases.
      
      Rework the per event channel lock to be non-blocking for the case of
      sending an event and removing the need for disabling interrupts for
      taking the lock.
      
      The lock is needed for avoiding races between event channel state
      changes (creation, closing, binding) against normal operations (set
      pending, [un]masking, priority changes).
      
      Use a rwlock, but with some restrictions:
      
      - Changing the state of an event channel (creation, closing, binding)
        needs to use write_lock(), with ASSERT()ing that the lock is taken as
        writer only when the state of the event channel is either before or
        after the locked region appropriate (either free or unbound).
      
      - Sending an event needs to use read_trylock() mostly, in case of not
        obtaining the lock the operation is omitted. This is needed as
        sending an event can happen with interrupts off (at least in some
        cases).
      
      - Dumping the event channel state for debug purposes is using
        read_trylock(), too, in order to avoid blocking in case the lock is
        taken as writer for a long time.
      
      - All other cases can use read_lock().
      
      Fixes: e045199c
      
       ("evtchn: address races with evtchn_reset()")
      Signed-off-by: Juergen Gross's avatarJuergen Gross <jgross@suse.com>
      Reviewed-by: Jan Beulich's avatarJan Beulich <jbeulich@suse.com>
      Acked-by: default avatarJulien Grall <jgrall@amazon.com>
      5f2df45e
    • Roger Pau Monné's avatar
      x86/msr: fix handling of MSR_IA32_PERF_{STATUS/CTL} · 30591787
      Roger Pau Monné authored
      Currently a PV hardware domain can also be given control over the CPU
      frequency, and such guest is allowed to write to MSR_IA32_PERF_CTL.
      However since commit 322ec7c8 the default behavior has been changed
      to reject accesses to not explicitly handled MSRs, preventing PV
      guests that manage CPU frequency from reading
      MSR_IA32_PERF_{STATUS/CTL}.
      
      Additionally some HVM guests (Windows at least) will attempt to read
      MSR_IA32_PERF_CTL and will panic if given back a #GP fault:
      
        vmx.c:3035:d8v0 RDMSR 0x00000199 unimplemented
        d8v0 VIRIDIAN CRASH: 3b c0000096 fffff806871c1651 ffffda0253683720 0
      
      Move the handling of MSR_IA32_PERF_{STATUS/CTL} to the common MSR
      handling shared between HVM and PV guests, and add an explicit case
      for reads to MSR_IA32_PERF_{STATUS/CTL}.
      
      Restore previous behavior and allow PV guests with the required
      permissions to read the contents of the mentioned MSRs. Non privileged
      guests will get 0 when trying to read those registers, as writes to
      MSR_IA32_PERF_CTL by such guest will already be silently dropped.
      
      Fixes: 322ec7c8 ('x86/pv: disallow access to unknown MSRs')
      Fixes: 84e848fd
      
       ('x86/hvm: disallow access to unknown MSRs')
      Signed-off-by: default avatarRoger Pau Monné <roger.pau@citrix.com>
      Signed-off-by: Andrew Cooper's avatarAndrew Cooper <andrew.cooper3@citrix.com>
      Reviewed-by: default avatarRoger Pau Monné <roger.pau@citrix.com>
      Reviewed-by: Jan Beulich's avatarJan Beulich <jbeulich@suse.com>
      30591787
  4. 06 Nov, 2020 8 commits
  5. 05 Nov, 2020 2 commits
  6. 04 Nov, 2020 4 commits
  7. 30 Oct, 2020 5 commits