Why Qubes/Xen is masking cet

User Support
1

My Xen CPUID dump shows them:

cet-ibt
cet-ss
cet-sss

Kernel has CONFIG_X86_CET=y

but ibt/shstk is absent in /proc/cpuinfo.

So:

  1. Why it is masked?
  2. Any security drawback to expose it?
  3. When not, is there a way to expose it?
2 
user@dom0:~ > zcat /proc/config.gz | grep -i kernel_ibt
CONFIG_X86_KERNEL_IBT=y

user@dom0:~ > zcat /proc/config.gz | grep -i user_shadow_stack
CONFIG_X86_USER_SHADOW_STACK=y
CONFIG_ARCH_HAS_USER_SHADOW_STACK=y

Does that help?

3

Thanks. It was very hepful resource to further investigate. As I stated in OP Xen CPUID dump shows them and the kernel supports it.

But something is masking it:

[user@dom0 ~]$ sudo xenhypfs cat /buildinfo/config | grep CONFIG_XEN_
CONFIG_XEN_SHSTK=y
CONFIG_XEN_IBT=y
…
[user@dom0 ~]$ sudo xl dmesg | grep -i -E ‘shadow|shstk|ibt|cet’
(XEN) Enabling Supervisor Shadow Stacks
(XEN) - IBT disabled in UEFI Runtime Services
…
[user@dom0 ~]$

So, we are coming back to my OP questions, why and how if possible… Obviously it is Xen that limits it but uses it for itself only…

Would you care to run the same 2 commands?

4

fyi

[user@dom0 ~]$ sudo xenhypfs cat /buildinfo/config | grep CONFIG_XEN_
CONFIG_XEN_SHSTK=y
CONFIG_XEN_IBT=y
CONFIG_XEN_ALIGN_DEFAULT=y
# CONFIG_XEN_ALIGN_2M is not set
# CONFIG_XEN_GUEST is not set
[user@dom0 ~]$ sudo xl dmesg | grep -i -E 'shadow|shstk|ibt|cet'
[user@dom0 ~]$ 

[user@dom0 ~]$ cat /etc/qubes-release 
Qubes release 4.2.4 (R4.2)
[user@dom0 ~]$ dnf info binutils | grep Version
Version      : 2.38
[user@dom0 ~]$ xl info | grep xen_version
xen_version            : 4.17.6
5 
user@dom0:~ >  xenhypfs cat /buildinfo/config | grep CONFIG_XEN_
CONFIG_XEN_SHSTK=y
CONFIG_XEN_IBT=y
CONFIG_XEN_ALIGN_DEFAULT=y
# CONFIG_XEN_ALIGN_2M is not set
# CONFIG_XEN_GUEST is not set
user@dom0:~ >  xl dmesg | grep -iE 'shadow|shstk|ibt|cet'
(XEN)   PV L1TF shadowing: Dom0 disabled, DomU disabled
(XEN)  - APIC TPR shadow
(XEN)  - VMCS shadowing

As for your questions, I don’t quite understand what you mean by masking.

6

Thanks to both of you. It is interesting that in your cases Xen doesn’t use cet even for itself (probably Xen< v4.19.x?)…

Me either. Masking, not exposing, hiding, disabling, not yet implemented for guests, I have no idea why this is going on. So, I am assuming terms. Cet is not available to guests (and here I consider even dom0 is guest to Xen) and I don’t know why, while that would be real additional layer by default instead of many user-defined “hardenings” we are constantly seeing here or elsewhere.

But for now I don’t want to discuss that point until we hopefully find out why it is not available to dom0 and other qubes.

@marmarek?

7

This Qubes OS version is not supported anymore.

Anyway, Xen should use CET for its own protection if hardware supports it. xl dmesg normally print those at startup:

(XEN) Enabling Supervisor Shadow Stacks
(XEN) Enabling Indirect Branch Tracking
8

Thanks. I am aware of this. It is used by Xen as I stated in the OP. The question is why it wouldn’t be exposed by Xen to dom0 and all the qubes?

9

AFAIK current Xen version doesn’t support exposing CET-SS/CET-IBT to VMs.

10

Yes, I have done tests that confirm that’s their implementation of it. I thought you might know why, since I can’t seem to find an argument for such decision. No resource on that matter.

Thanks anyway.

P.S. Do you think it would be good to have it available for Qubes qubes including dom0?

11

I don’t think anybody “decided to not expose it”, but simply nobody implemented support for CET for VMs. It is not as simple as let the VM see relevant CPUID bits, but it actually need to properly function. I guess patches welcome.