This config changes some of the defaults for extra compatibility and some extra hardening. I'll attempt to explain my reasoning for each option of interest below.
CONFIG_PV32:
This is something I would be fine with turning off, but
users may be depending on this or use 32bit PV shims.
CONFIG_XEN_GUEST:
Allow Xen runing under Xen, this may be useful to test certain
configurations. We should probably list in the wiki that those
types of configurations are not suitable for production however.
CONFIG_PV_SHIM:
Allow legacy PV guests to run in a HVM/PVH container. This is
useful to keep legacy PV guests running without modification.
CONFIG_HYPERV_GUEST:
Allows Xen to detect it's running under Hyper-V. This may be
useful for testing Xen in certain situations. We're not size
constrained so it shouldn't hurt to enable this.
CONFIG_REQUIRE_NX:
No-eXecute, aka execute disable, aka data execution prevention
(DEP), is a security feature to disable memory from being
executed as instructions. Xen supports this by default, however
without requiring this Xen could in theory be exploited to
assume that this feature is unavailable. Requiring this will
prevent Xen from booting in cases where NX is unavailable. The
very small downside is that some very early Pentium 4 processors
lack this feature. A small sacrifice to make for some
significant hardening.
CONFIG_EFI_SET_VIRTUAL_ADDRESS_MAP:
Call EFI SetVirtualAddressMap() runtime service to setup memory
map for further runtime services. Many UEFI implementations
misbehave when this call is missing. Should improve
compatibility.
CONFIG_XSM:
Allows users to use Xen Security Modules to further harden their
setup. Later config options will set this to be disabled by
default.
CONFIG_XSM_FLASK:
Enables FLux Advanced Security Kernel as the access control
mechanism used by the XSM framework. It uses the same
configuration language as SELinux. It provides MAC capabilities
giving one fine granular control over what a VM can do.
CONFIG_XSM_FLASK_AVC_STATS:
Maintains counters on the access vector cache that can be viewed
using the FLASK_AVC_CACHESTATS sub-op of the xsm_op hypercall.
This is useful for auditing FLASK configurations.
CONFIG_XSM_SILO:
Enables SILO as the access control mechanism used by the XSM
framework. This will deny any unmediated communication channels
between unprivileged VMs. This is an alternative to the FLASK
XSM module.
CONFIG_XSM_DUMMY_DEFAULT:
Default to non-XSM behavior.
CONFIG_LATE_HWDOM:
Allows the creation of a dedicated hardware domain distinct from
domain 0 that manages devices without needing access to other
privileged functionality such as the ability to manage domains.
This requires that dom0 is a stub domain that constructs the
hardware domains instead of initializing the hardware itself.
This feature is useful for "dom0less" setups. It does nothing by
default.
CONFIG_LIVEPATCH=n:
I explicitly disabled this feature as I don't even know where or
how to begin to test this. Live patching has a tendency to fail,
so if we want to support this we should be applying live
patching related patches from XenServer.
CONFIG_ENFORCE_UNIQUE_SYMBOLS=n:
Related to live patching, see above.
CONFIG_SERIAL_TX_BUFSIZE=131072:
This is the default set by XenServer, who set it to 128KiB from
the default 32KiB. I assume this speeds up serial connections or
makes them more reliable.
CONFIG_AMD_IOMMU:
Enables IOMMU support on AMD platforms implementing AMD-Vi.
Required if the system has more than 256 CPUs. As far as I know
this will also make Xen respect the IOMMU when it comes to PCI
passthrough. When doing PCI passthrough it's important that
devices sharing an IOMMU group are not passed through
separately. Doing so allows an attacker to use DMA to sniff the
other device or even do DMA through it. If the other device is
still attached to dom0 the attacker will be able to do malicious
DMA on dom0.
CONFIG_INTEL_IOMMU:
The same as the above, but for Intel VT-d.
CONFIG_GDBSX:
Allow debugging guests from dom0 via gdbsx. This is useful for
driver development.
CONFIG_SCRUB_DEBUG:
Verifies that pages that need to be scrubbed before being
allocated to a guest are indeed scrubbed. I assume this halts
Xen if this is not the case. This is useful for detecting
hardware errors and potential exploitation of Xen. My aim is to
harden Xen by enabling this option.
This config changes some of the defaults for extra compatibility and some extra hardening. I'll attempt to explain my reasoning for each option of interest below.
CONFIG_PV32: This is something I would be fine with turning off, but users may be depending on this or use 32bit PV shims.CONFIG_XEN_GUEST: Allow Xen runing under Xen, this may be useful to test certain configurations. We should probably list in the wiki that those types of configurations are not suitable for production however.CONFIG_PV_SHIM: Allow legacy PV guests to run in a HVM/PVH container. This is useful to keep legacy PV guests running without modification.CONFIG_HYPERV_GUEST: Allows Xen to detect it's running under Hyper-V. This may be useful for testing Xen in certain situations. We're not size constrained so it shouldn't hurt to enable this.CONFIG_REQUIRE_NX: No-eXecute, aka execute disable, aka data execution prevention (DEP), is a security feature to disable memory from being executed as instructions. Xen supports this by default, however without requiring this Xen could in theory be exploited to assume that this feature is unavailable. Requiring this will prevent Xen from booting in cases where NX is unavailable. The very small downside is that some very early Pentium 4 processors lack this feature. A small sacrifice to make for some significant hardening.CONFIG_EFI_SET_VIRTUAL_ADDRESS_MAP: Call EFISetVirtualAddressMap()runtime service to setup memory map for further runtime services. Many UEFI implementations misbehave when this call is missing. Should improve compatibility.CONFIG_XSM: Allows users to use Xen Security Modules to further harden their setup. Later config options will set this to be disabled by default.CONFIG_XSM_FLASK: Enables FLux Advanced Security Kernel as the access control mechanism used by the XSM framework. It uses the same configuration language as SELinux. It provides MAC capabilities giving one fine granular control over what a VM can do.CONFIG_XSM_FLASK_AVC_STATS: Maintains counters on the access vector cache that can be viewed using the FLASK_AVC_CACHESTATS sub-op of the xsm_op hypercall. This is useful for auditing FLASK configurations.CONFIG_XSM_SILO: Enables SILO as the access control mechanism used by the XSM framework. This will deny any unmediated communication channels between unprivileged VMs. This is an alternative to the FLASK XSM module.CONFIG_XSM_DUMMY_DEFAULT: Default to non-XSM behavior.CONFIG_LATE_HWDOM: Allows the creation of a dedicated hardware domain distinct from domain 0 that manages devices without needing access to other privileged functionality such as the ability to manage domains. This requires that dom0 is a stub domain that constructs the hardware domains instead of initializing the hardware itself. This feature is useful for "dom0less" setups. It does nothing by default.CONFIG_LIVEPATCH=n: I explicitly disabled this feature as I don't even know where or how to begin to test this. Live patching has a tendency to fail, so if we want to support this we should be applying live patching related patches from XenServer.CONFIG_ENFORCE_UNIQUE_SYMBOLS=n: Related to live patching, see above.CONFIG_SERIAL_TX_BUFSIZE=131072: This is the default set by XenServer, who set it to 128KiB from the default 32KiB. I assume this speeds up serial connections or makes them more reliable.CONFIG_AMD_IOMMU: Enables IOMMU support on AMD platforms implementing AMD-Vi. Required if the system has more than 256 CPUs. As far as I know this will also make Xen respect the IOMMU when it comes to PCI passthrough. When doing PCI passthrough it's important that devices sharing an IOMMU group are not passed through separately. Doing so allows an attacker to use DMA to sniff the other device or even do DMA through it. If the other device is still attached to dom0 the attacker will be able to do malicious DMA on dom0.CONFIG_INTEL_IOMMU: The same as the above, but for Intel VT-d.CONFIG_GDBSX: Allow debugging guests from dom0 via gdbsx. This is useful for driver development.CONFIG_SCRUB_DEBUG: Verifies that pages that need to be scrubbed before being allocated to a guest are indeed scrubbed. I assume this halts Xen if this is not the case. This is useful for detecting hardware errors and potential exploitation of Xen. My aim is to harden Xen by enabling this option.