+* ``tsx=off``: This parameter is already set by default thanks to
+ ``CONFIG_X86_INTEL_TSX_MODE_OFF``. It deactivates the Intel TSX feature on
+ CPUs that support TSX control (i.e. are recent enough or received a microcode
+ update) and that are not already vulnerable to MDS, therefore mitigating the
+ TSX Asynchronous Abort (TAA) Intel CPU vulnerability.
+* ``tsx_async_abort``: This parameter controls optional mitigations for the TSX
+ Asynchronous Abort (TAA) Intel CPU vulnerability. Due to our use of
+ ``mds=full,nosmt`` in addition to ``CONFIG_X86_INTEL_TSX_MODE_OFF``, CLIP OS
+ is already protected against this vulnerability as long as the CPU microcode
+ has been updated, whether or not the CPU is affected by MDS. For the record,
+ if we wanted to keep TSX activated, we could specify
+ ``tsx_async_abort=full,nosmt``. Not specifying this parameter is equivalent
+ to setting ``tsx_async_abort=full``, which leaves SMT enabled and therefore
+ is not a complete mitigation. Note that this mitigation requires an Intel
+ microcode update and has no effect on systems that are already affected by
+ MDS and enable mitigations against it, nor on systems that disable TSX.
+* ``kvm.nx_huge_pages``: This parameter allows to control the KVM hypervisor
+ iTLB multihit mitigations. Such mitigations are not needed as long as CLIP OS
+ is not used as an hypervisor with untrusted guest VMs. If it were to be
+ someday, ``kvm.nx_huge_pages=force`` should be used to ensure that guests
+ cannot exploit the iTLB multihit erratum to crash the host.
+* ``mitigations``: This parameter controls optional mitigations for CPU
+ vulnerabilities in an arch-independent and more coarse-grained way. For now,
+ we keep using arch-specific options for the sake of explicitness. Not setting
+ this parameter equals setting it to ``auto``, which itself does not update
+ anything.
+* ``init_on_free=1`` is automatically set due to ``INIT_ON_FREE_DEFAULT_ON``. It
+ zero-fills page and slab allocations on free to reduce risks of information
+ leaks and help mitigate a subset of use-after-free vulnerabilities.
+* ``init_on_alloc=1`` is automatically set due to ``INIT_ON_ALLOC_DEFAULT_ON``.
+ The purpose of this functionality is to eliminate several kinds of
+ *uninitialized heap memory* flaws by zero-filling:
+
+ * all page allocator and slab allocator memory when allocated: this is
+ already guaranteed by our use of ``init_on_free`` in combination with
+ ``PAGE_SANITIZE_VERIFY`` and ``SLAB_SANITIZE_VERIFY`` from linux-hardened,
+ and thus has no effect;
+ * a few more *special* objects when allocated: these are the ones for which
+ we enable ``init_on_alloc`` as they are not covered by the aforementioned
+ combination of ``init_on_free`` and ``SANITIZE_VERIFY`` features.