path: root/xen/common/Kconfig

menu "Common Features"

config COMPAT
	bool
	help
	  32-bit interface support on 64-bit Xen which is used for both
	  HVM and PV guests. HVMLoader makes 32-bit hypercalls irrespective
	  of the destination runmode of the guest.

config CORE_PARKING
	bool

config GRANT_TABLE
	bool "Grant table support" if EXPERT
	default y
	---help---
	  Grant table provides a generic mechanism to memory sharing
	  between domains. This shared memory interface underpins the
	  split device drivers for block and network IO in a classic
	  Xen setup.

	  If unsure, say Y.

config HAS_ALTERNATIVE
	bool

config HAS_DEVICE_TREE
	bool

config HAS_EX_TABLE
	bool

config HAS_FAST_MULTIPLY
	bool

config HAS_IOPORTS
	bool

config HAS_KEXEC
	bool

config HAS_MEM_PAGING
	bool

config HAS_PDX
	bool

config HAS_SCHED_GRANULARITY
	bool

config HAS_UBSAN
	bool

config MEM_ACCESS_ALWAYS_ON
	bool

config MEM_ACCESS
	def_bool MEM_ACCESS_ALWAYS_ON
	prompt "Memory Access and VM events" if !MEM_ACCESS_ALWAYS_ON
	---help---

	  Framework to configure memory access types for guests and receive
	  related events in userspace.

config NEEDS_LIBELF
	bool

config NEEDS_LIST_SORT
	bool

menu "Speculative hardening"

config SPECULATIVE_HARDEN_ARRAY
	bool "Speculative Array Hardening"
	default y
	---help---
	  Contemporary processors may use speculative execution as a
	  performance optimisation, but this can potentially be abused by an
	  attacker to leak data via speculative sidechannels.

	  One source of data leakage is via speculative out-of-bounds array
	  accesses.

	  When enabled, specific array accesses which have been deemed liable
	  to be speculatively abused will be hardened to avoid out-of-bounds
	  accesses.

	  This is a best-effort mitigation.  There are no guarantees that all
	  areas of code open to abuse have been hardened.

	  If unsure, say Y.

config SPECULATIVE_HARDEN_BRANCH
	bool "Speculative Branch Hardening"
	default y
	depends on X86
        ---help---
	  Contemporary processors may use speculative execution as a
	  performance optimisation, but this can potentially be abused by an
	  attacker to leak data via speculative sidechannels.

	  One source of misbehaviour is by executing the wrong basic block
	  following a conditional jump.

	  When enabled, specific conditions which have been deemed liable to
	  be speculatively abused will be hardened to avoid entering the wrong
	  basic block.

	  This is a best-effort mitigation.  There are no guarantees that all
	  areas of code open to abuse have been hardened, nor that
	  optimisations in the compiler haven't subverted the attempts to
	  harden.

	  If unsure, say Y.

endmenu

config HYPFS
	bool "Hypervisor file system support"
	default y
	---help---
	  Support Xen hypervisor file system. This file system is used to
	  present various hypervisor internal data to dom0 and in some
	  cases to allow modifying settings. Disabling the support will
	  result in some features not being available, e.g. runtime parameter
	  setting.

	  If unsure, say Y.

config HYPFS_CONFIG
	bool "Provide hypervisor .config via hypfs entry"
	default y
	depends on HYPFS
	---help---
	  When enabled the contents of the .config file used to build the
	  hypervisor are provided via the hypfs entry /buildinfo/config.

	  Disable this option in case you want to spare some memory or you
	  want to hide the .config contents from dom0.

config IOREQ_SERVER
	bool

config KEXEC
	bool "kexec support"
	default y
	depends on HAS_KEXEC
	---help---
	  Allows a running Xen hypervisor to be replaced with another OS
	  without rebooting. This is primarily used to execute a crash
	  environment to collect information on a Xen hypervisor or dom0 crash.

	  If unsure, say Y.

config EFI_SET_VIRTUAL_ADDRESS_MAP
    bool "EFI: call SetVirtualAddressMap()" if EXPERT
    ---help---
      Call EFI SetVirtualAddressMap() runtime service to setup memory map for
      further runtime services. According to UEFI spec, it isn't strictly
      necessary, but many UEFI implementations misbehave when this call is
      missing.

      If unsure, say N.

config XENOPROF
	def_bool y
	prompt "Xen Oprofile Support" if EXPERT
	depends on X86
	---help---
	  Xen OProfile (Xenoprof) is a system-wide profiler for Xen virtual
	  machine environments, capable of profiling the Xen virtual machine
	  monitor, multiple Linux guest operating systems, and applications
	  running on them.

	  If unsure, say Y.

config XSM
	bool "Xen Security Modules support"
	default ARM
	---help---
	  Enables the security framework known as Xen Security Modules which
	  allows administrators fine-grained control over a Xen domain and
	  its capabilities by defining permissible interactions between domains,
	  the hypervisor itself, and related resources such as memory and
	  devices.

	  If unsure, say N.

config XSM_FLASK
	def_bool y
	prompt "FLux Advanced Security Kernel support"
	depends on XSM
	---help---
	  Enables FLASK (FLux Advanced Security Kernel) as the access control
	  mechanism used by the XSM framework.  This provides a mandatory access
	  control framework by which security enforcement, isolation, and
	  auditing can be achieved with fine granular control via a security
	  policy.

	  If unsure, say Y.

config XSM_FLASK_AVC_STATS
	def_bool y
	prompt "Maintain statistics on the FLASK access vector cache" if EXPERT
	depends on XSM_FLASK
	---help---
	  Maintain counters on the access vector cache that can be viewed using
	  the FLASK_AVC_CACHESTATS sub-op of the xsm_op hypercall.  Disabling
	  this will save a tiny amount of memory and time to update the stats.

	  If unsure, say Y.

config XSM_FLASK_POLICY
	bool "Compile Xen with a built-in FLASK security policy"
	default y if "$(XEN_HAS_CHECKPOLICY)" = "y"
	depends on XSM_FLASK
	---help---
	  This includes a default XSM policy in the hypervisor so that the
	  bootloader does not need to load a policy to get sane behavior from an
	  XSM-enabled hypervisor.  If this is disabled, a policy must be
	  provided by the bootloader or by Domain 0.  Even if this is enabled, a
	  policy provided by the bootloader will override it.

	  This requires that the SELinux policy compiler (checkpolicy) be
	  available when compiling the hypervisor.

	  If unsure, say Y.

config XSM_SILO
	def_bool y
	prompt "SILO support"
	depends on XSM
	---help---
	  Enables SILO as the access control mechanism used by the XSM framework.
	  This is not the default module, add boot parameter xsm=silo to choose
	  it. This will deny any unmediated communication channels (grant tables
	  and event channels) between unprivileged VMs.

	  If unsure, say Y.

choice
	prompt "Default XSM implementation"
	depends on XSM
	default XSM_SILO_DEFAULT if XSM_SILO && ARM
	default XSM_FLASK_DEFAULT if XSM_FLASK
	default XSM_SILO_DEFAULT if XSM_SILO
	default XSM_DUMMY_DEFAULT
	config XSM_DUMMY_DEFAULT
		bool "Match non-XSM behavior"
	config XSM_FLASK_DEFAULT
		bool "FLux Advanced Security Kernel" if XSM_FLASK
	config XSM_SILO_DEFAULT
		bool "SILO" if XSM_SILO
endchoice

config LATE_HWDOM
	bool "Dedicated hardware domain"
	default n
	depends on XSM && X86
	---help---
	  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 the actual domain 0 be a stub domain that
	  constructs the actual hardware domain instead of initializing the
	  hardware itself.  Because the hardware domain needs access to
	  hypercalls not available to unprivileged guests, an XSM policy
	  is required to properly define the privilege of these domains.

	  This feature does nothing if the "hardware_dom" boot parameter is
	  not present.  If this feature is being used for security, it should
	  be combined with an IOMMU in strict mode.

	  If unsure, say N.

config ARGO
	bool "Argo: hypervisor-mediated interdomain communication" if EXPERT
	---help---
	  Enables a hypercall for domains to ask the hypervisor to perform
	  data transfer of messages between domains.

	  This allows communication channels to be established that do not
	  require any shared memory between domains; the hypervisor is the
	  entity that each domain interacts with. The hypervisor is able to
	  enforce Mandatory Access Control policy over the communication.

	  If XSM_FLASK is enabled, XSM policy can govern which domains may
	  communicate via the Argo system.

	  This feature does nothing if the "argo" boot parameter is not present.
	  Argo is disabled at runtime by default.

	  If unsure, say N.

source "common/sched/Kconfig"

config CRYPTO
	bool

config LIVEPATCH
	bool "Live patching support"
	default X86
	depends on "$(XEN_HAS_BUILD_ID)" = "y"
	---help---
	  Allows a running Xen hypervisor to be dynamically patched using
	  binary patches without rebooting. This is primarily used to binarily
	  patch in the field an hypervisor with XSA fixes.

	  If unsure, say Y.

config FAST_SYMBOL_LOOKUP
	bool "Fast symbol lookup (bigger binary)"
	default y
	depends on LIVEPATCH
	---help---
	  When searching for symbol addresses we can use the built-in system
	  that is optimized for searching symbols using addresses as the key.
	  However using it for the inverse (find address using the symbol name)
	  it is slow. This extra data and code (~55kB) speeds up the search.
	  The only user of this is Live patching.

	  If unsure, say Y.

config ENFORCE_UNIQUE_SYMBOLS
	bool "Enforce unique symbols"
	default LIVEPATCH
	---help---
	  Multiple symbols with the same name aren't generally a problem
	  unless livepatching is to be used.

	  Livepatch loading involves resolving relocations against symbol
	  names, and attempting to a duplicate symbol in a livepatch will
	  result in incorrect livepatch application.

	  This option should be used to ensure that a build of Xen can have a
	  livepatch build and apply correctly.

config SUPPRESS_DUPLICATE_SYMBOL_WARNINGS
	bool "Suppress duplicate symbol warnings"
	depends on !ENFORCE_UNIQUE_SYMBOLS
	---help---
	  Multiple symbols with the same name aren't generally a problem
	  unless Live patching is to be used, so these warnings can be
	  suppressed by enabling this option.  Certain other options (known
	  to produce many duplicate names) may select this to avoid the
	  build becoming overly verbose.

config CMDLINE
	string "Built-in hypervisor command string" if EXPERT
	default ""
	---help---
	  Enter arguments here that should be compiled into the hypervisor
	  image and used at boot time. When the system boots, this string
	  will be parsed prior to the bootloader command line. So if a
	  non-cumulative option is set both in this string and in the
	  bootloader command line, only the latter one will take effect.

config CMDLINE_OVERRIDE
	bool "Built-in command line overrides bootloader arguments"
	default n
	depends on CMDLINE != ""
	---help---
	  Set this option to 'Y' to have the hypervisor ignore the bootloader
	  command line, and use ONLY the built-in command line.

	  This is used to work around broken bootloaders. This should
	  be set to 'N' under normal conditions.

config DOM0_MEM
	string "Default value for dom0_mem boot parameter"
	default ""
	---help---
	  Sets a default value for dom0_mem, e.g. "512M".
	  The specified string will be used for the dom0_mem parameter in
	  case it was not specified on the command line.

	  See docs/misc/xen-command-line.markdown for the supported syntax.

	  Leave empty if you are not sure what to specify.

config TRACEBUFFER
	bool "Enable tracing infrastructure" if EXPERT
	default y
	---help---
	  Enable tracing infrastructure and pre-defined tracepoints within Xen.
	  This will allow live information about Xen's execution and performance
	  to be collected at run time for debugging or performance analysis.
	  Memory and execution overhead when not active is minimal.

endmenu