Amd ryzen 5 3600 - Speculative Store Bypass

User Support Hardware Issues
,
1

hey there

Anyone running Qubes on Ryzen 5 cpu ?
If you do, are you vulnerable against Speculative Store Bypass ? Old topic, I know
I have the latest R4.2.4
I have the same output for 3400G and 3600 cpus

Vulnerabilities:             
  Gather data sampling:      Not affected
  Indirect target selection: Not affected
  Itlb multihit:             Not affected
  L1tf:                      Not affected
  Mds:                       Not affected
  Meltdown:                  Not affected
  Mmio stale data:           Not affected
  Reg file data sampling:    Not affected
  Retbleed:                  Mitigation; untrained return thunk; SMT disabled
  Spec rstack overflow:      Mitigation; SMT disabled
  Spec store bypass:         Vulnerable
  Spectre v1:                Mitigation; usercopy/swapgs barriers and __user pointer sanitization
  Spectre v2:                Mitigation; Retpolines; IBPB conditional; STIBP disabled; RSB filling; PBRSB-eIBRS Not affected; BHI Not affected
  Srbds:                     Not affected
  Tsa:                       Not affected
  Tsx async abort:           Not affected

(XEN) Speculative mitigation facilities:
(XEN)   Hardware hints: IBRS_FAST IBRS_SAME_MODE
(XEN)   Hardware features: IBPB STIBP SSBD
(XEN)   Compiled-in support: INDIRECT_THUNK RETURN_THUNK HARDEN_ARRAY HARDEN_BRANCH HARDEN_GUEST_ACCESS HARDEN_LOCK
(XEN)   Xen settings: BTI-Thunk: RETPOLINE, SPEC_CTRL: No STIBP+ SSBD+, Other: BRANCH_HARDEN
(XEN)   Support for HVM VMs: RSB IBPB-entry
(XEN)   Support for PV VMs: IBPB-entry
(XEN)   XPTI (64-bit PV only): Dom0 disabled, DomU disabled (without PCID)
(XEN)   PV L1TF shadowing: Dom0 disabled, DomU disabled

I tried ā€˜spec-ctrl=ssbd=1ā€™ on the xen command line, I see it applies with SSBD+ in ā€˜xl dmesgā€™ but I also see ā€˜SPEC_CTRL: Noā€™ , which Iā€™m unable to control and looks like its dependent on IBRS support.

Am I overlooking something, or I have to live with it (I would be surprised)?

much appreciated

edit: ā€˜s/smt-ctl=ssbd=1/spec-ctrl=ssbd=1/ā€™

1 Like
2

https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-040-2018.txt

You can use spec-ctrl=ssbd=true to enable mitigation, but the QSB saying it comes with a performance penalty.

  1. We concur with the analysis in XSA-263 that this vulnerability
    presents minimal risk to Xen itself and minimal risk of inter-guest
    attacks. Therefore, we believe that proper compartmentalization is
    sufficient for Qubes users to mitigate this issue without having to
    enable SSBD globally.

I think the Spec store bypass: Vulnerable is because it canā€™t be enabled locally for AMD CPUs, you can only use the global mitigation.

1 Like
3

If Iā€™m understanding correctly, these mitigations are only necessary to protect against information leakage inside individual qubes.

OTOH, I found some articles at Phoronix, which suggest that there isnā€™t a huge performance impact for AMD processors. (The tests all seem to show less than 10% loss.)

I guess it is always most important to use the protection given by Qubes-os VM isolation to the maximum (since we know that similar vulnerabilities are regularly discovered.).

4

hi, renehoj, yes-yes, I did that with ā€˜spec-crtl=ssbd=1ā€™ (and true as well), I did a typo (I do that a lot recently) in my initial message
thanks for the link, I read that, but still ā€œVulnerableā€ hurts my eye:)
that is why I thoght to give a go with global, to see if it works, but looks like not

5

thanks, phceac
yes, exactly, first I would like to see its mitigated, then I would worry about slowdown

1 Like