path: root/static/freebsd/man7/mitigations.7 3.html

<table class="head">
  <tr>
    <td class="head-ltitle">MITIGATIONS(7)</td>
    <td class="head-vol">Miscellaneous Information Manual</td>
    <td class="head-rtitle">MITIGATIONS(7)</td>
  </tr>
</table>
<div class="manual-text">
<section class="Sh">
<h1 class="Sh" id="NAME"><a class="permalink" href="#NAME">NAME</a></h1>
<p class="Pp"><code class="Nm">mitigations</code> &#x2014;
    <span class="Nd">FreeBSD Security Vulnerability Mitigations</span></p>
</section>
<section class="Sh">
<h1 class="Sh" id="SYNOPSIS"><a class="permalink" href="#SYNOPSIS">SYNOPSIS</a></h1>
<p class="Pp">In <span class="Ux">FreeBSD</span>, various security mitigations
    are employed to limit the impact of vulnerabilities and protect the system
    from malicious attacks. Some of these mitigations have run-time controls to
    enable them on a global or per-process basis, some are optionally enabled or
    disabled at compile time, and some are inherent to the implementation and
    have no controls.</p>
<p class="Pp">The following vulnerability mitigations are covered in this
    document:</p>
<p class="Pp"></p>
<ul class="Bl-bullet Bl-compact">
  <li>Address Space Layout Randomization (ASLR)</li>
  <li>Position Independent Executable (PIE)</li>
  <li>Write XOR Execute page protection policy</li>
  <li id="PROT_MAX"><a class="permalink" href="#PROT_MAX"><code class="Dv">PROT_MAX</code></a></li>
  <li>Relocation Read-Only (RELRO)</li>
  <li>Bind Now</li>
  <li>Stack Overflow Protection</li>
  <li>Supervisor Mode Memory Protection</li>
  <li>Capsicum</li>
  <li>Firmware and Microcode</li>
  <li>Architectural Vulnerability Mitigations</li>
</ul>
<p class="Pp">Please note that the effectiveness and availability of these
    mitigations may vary depending on the <span class="Ux">FreeBSD</span>
    version and system configuration.</p>
</section>
<section class="Sh">
<h1 class="Sh" id="DESCRIPTION"><a class="permalink" href="#DESCRIPTION">DESCRIPTION</a></h1>
<p class="Pp">Security vulnerability mitigations are techniques employed in
    <span class="Ux">FreeBSD</span> to limit the potential impact of security
    vulnerabilities in software and hardware. It is essential to understand that
    mitigations do not directly address the underlying security issues. They are
    not a substitute for secure coding practices. Mitigations serve as an
    additional layer of defense, helping to reduce the likelihood of a
    successful exploitation of vulnerabilities by making it more difficult for
    attackers to achieve their objectives.</p>
<p class="Pp">This manual page describes the security mitigations implemented in
    <span class="Ux">FreeBSD</span> to enhance the overall security of the
    operating system. Each mitigation is designed to protect against specific
    types of attacks and vulnerabilities.</p>
</section>
<section class="Sh">
<h1 class="Sh" id="SOFTWARE_VULNERABILITY_MITIGATIONS"><a class="permalink" href="#SOFTWARE_VULNERABILITY_MITIGATIONS">SOFTWARE
  VULNERABILITY MITIGATIONS</a></h1>
<section class="Ss">
<h2 class="Ss" id="Address_Space_Layout_Randomization_(ASLR)"><a class="permalink" href="#Address_Space_Layout_Randomization_(ASLR)">Address
  Space Layout Randomization (ASLR)</a></h2>
<p class="Pp">Address Space Layout Randomization (ASLR) is a security mitigation
    technique that works by randomizing the memory addresses where system and
    application code, data, and libraries are loaded, making it more challenging
    for attackers to predict the memory layout and exploit vulnerabilities.</p>
<p class="Pp">ASLR introduces randomness into the memory layout during process
    execution, reducing the predictability of memory addresses. ASLR is intended
    to make exploitation more difficult in the event that an attacker discovers
    a software vulnerability, such as a buffer overflow.</p>
<p class="Pp">ASLR can be enabled on both a global and per-process basis. Global
    control is provided by a separate set of <a class="Xr">sysctl(8)</a> knobs
    for 32- and 64-bit processes. It can be or disabled on a per-process basis
    via <a class="Xr">proccontrol(1)</a>. Note that an ASLR mode change takes
    effect upon address space change, i.e., upon
  <a class="Xr">execve(2)</a>.</p>
<p class="Pp">Global controls for 32-bit processes:</p>
<dl class="Bl-tag">
  <dt id="kern.elf32.aslr.enable"><var class="Va">kern.elf32.aslr.enable</var></dt>
  <dd>Enable ASLR for 32-bit ELF binaries, other than Position Independent
      Executable (PIE) binaries.</dd>
  <dt id="kern.elf32.aslr.pie_enable"><var class="Va">kern.elf32.aslr.pie_enable</var></dt>
  <dd>Enable ASLR for 32-bit Position Independent Executable (PIE) ELF
    binaries.</dd>
  <dt id="kern.elf32.aslr.honor_sbrk"><var class="Va">kern.elf32.aslr.honor_sbrk</var></dt>
  <dd>Reserve the legacy <a class="Xr">sbrk(2)</a> region for compatibility with
      older binaries.</dd>
  <dt id="kern.elf32.aslr.stack"><var class="Va">kern.elf32.aslr.stack</var></dt>
  <dd>Randomize the stack location for 32-bit ELF binaries.</dd>
</dl>
<p class="Pp">Global controls for 64-bit processes:</p>
<dl class="Bl-tag">
  <dt id="kern.elf64.aslr.enable"><var class="Va">kern.elf64.aslr.enable</var></dt>
  <dd>Enable ASLR for 64-bit ELF binaries, other than Position Independent
      Executable (PIE) binaries.</dd>
  <dt id="kern.elf64.aslr.pie_enable"><var class="Va">kern.elf64.aslr.pie_enable</var></dt>
  <dd>Enable ASLR for 64-bit Position Independent Executable (PIE) ELF
    binaries.</dd>
  <dt id="kern.elf64.aslr.honor_sbrk"><var class="Va">kern.elf64.aslr.honor_sbrk</var></dt>
  <dd>Reserve the legacy <a class="Xr">sbrk(2)</a> region for compatibility with
      older binaries.</dd>
  <dt id="kern.elf64.aslr.stack"><var class="Va">kern.elf64.aslr.stack</var></dt>
  <dd>Randomize the stack location for 64-bit ELF binaries.</dd>
</dl>
<p class="Pp">To execute a command with ASLR enabled or disabled:</p>
<p class="Pp">proccontrol <code class="Fl">-m</code> <var class="Ar">aslr</var>
    [<code class="Fl">-s</code> <var class="Ar">enable</var> |
    <var class="Ar">disable</var>] <var class="Ar">command</var></p>
</section>
<section class="Ss">
<h2 class="Ss" id="Position_Independent_Executable_(PIE)"><a class="permalink" href="#Position_Independent_Executable_(PIE)">Position
  Independent Executable (PIE)</a></h2>
<p class="Pp">PIE binaries are executable files that do not have a fixed load
    address. They can be loaded at an arbitrary memory address by the
    <a class="Xr">rtld(1)</a> run-time linker. With ASLR they are loaded at a
    random address on each execution.</p>
</section>
<section class="Ss">
<h2 class="Ss" id="Write_XOR_Execute_page_protection_policy"><a class="permalink" href="#Write_XOR_Execute_page_protection_policy">Write
  XOR Execute page protection policy</a></h2>
<p class="Pp">Write XOR Execute (W^X) is a vulnerability mitigation strategy
    that strengthens the security of the system by controlling memory access
    permissions.</p>
<p class="Pp">Under the W^X mitigation, memory pages may be writable (W) or
    executable (E), but not both at the same time. This means that code
    execution is prevented in areas of memory that are designated as writable,
    and writing or modification of memory is restricted in areas marked for
    execution. Applications that perform Just In Time (JIT) compilation need to
    be adapted to be compatible with W^X.</p>
<p class="Pp">There are separate <a class="Xr">sysctl(8)</a> knobs to control
    W^X policy enforcement for 32- and 64-bit processes. The W^X policy is
    enabled by setting the appropriate <code class="Dv">allow_wx</code> sysctl
    to 0.</p>
<dl class="Bl-tag">
  <dt id="kern.elf32.allow_wx"><var class="Va">kern.elf32.allow_wx</var></dt>
  <dd>Allow 32-bit processes to map pages simultaneously writable and
      executable.</dd>
  <dt id="kern.elf64.allow_wx"><var class="Va">kern.elf64.allow_wx</var></dt>
  <dd>Allow 64-bit processes to map pages simultaneously writable and
      executable.</dd>
</dl>
</section>
<section class="Ss">
<h2 class="Ss" id="PROT_MAX~2"><a class="permalink" href="#PROT_MAX~2">PROT_MAX</a></h2>
<p class="Pp"><code class="Dv">PROT_MAX</code> is a
    <span class="Ux">FreeBSD</span>-specific extension to
    <a class="Xr">mmap(2)</a>. <code class="Dv">PROT_MAX</code> provides the
    ability to set the maximum protection of a region allocated by
    <a class="Xr">mmap(2)</a> and later altered by
    <a class="Xr">mprotect(2)</a>. For example, memory allocated originally with
    an mmap prot argument of PROT_MAX(PROT_READ | PROT_WRITE) | PROT_READ may be
    made writable by a future <a class="Xr">mprotect(2)</a> call, but may not be
    made executable.</p>
</section>
<section class="Ss">
<h2 class="Ss" id="Relocation_Read-Only_(RELRO)"><a class="permalink" href="#Relocation_Read-Only_(RELRO)">Relocation
  Read-Only (RELRO)</a></h2>
<p class="Pp">Relocation Read-Only (RELRO) is a mitigation tool that makes
    certain portions of a program's address space that contain ELF metadata
    read-only, after relocation processing by <a class="Xr">rtld(1)</a>.</p>
<p class="Pp" id="partial">When enabled in isolation the RELRO option provides
    <a class="permalink" href="#partial"><i class="Em">partial RELRO</i></a>
    support. In this case the Procedure Linkage Table (PLT)-related part of the
    Global Offset Table (GOT) (in the section typically named .got.plt) remains
    writable.</p>
<p class="Pp">RELRO is enabled by default. The <a class="Xr">src.conf(5)</a>
    build-time option <var class="Va">WITHOUT_RELRO</var> may be used to disable
    it.</p>
</section>
<section class="Ss">
<h2 class="Ss" id="BIND_NOW"><a class="permalink" href="#BIND_NOW">BIND_NOW</a></h2>
<p class="Pp">The <var class="Va">WITH_BIND_NOW</var>
    <a class="Xr">src.conf(5)</a> build-time option causes binaries to be built
    with the <code class="Dv">DF_BIND_NOW</code> flag set. The run-time loader
    <a class="Xr">rtld(1)</a> will then perform all relocation processing when
    the process starts, instead of on demand (on the first access to each
    symbol).</p>
<p class="Pp" id="full">When enabled in combination with
    <code class="Dv">RELRO</code> (which is enabled by default) this provides
    <a class="permalink" href="#full"><i class="Em">full RELRO</i></a>. The
    entire GOT (.got and .got.plt) are made read-only at program startup,
    preventing attacks on the relocation table. Note that this results in a
    nonstandard Application Binary Interface (ABI), and it is possible that some
    applications may not function correctly.</p>
</section>
<section class="Ss">
<h2 class="Ss" id="Stack_Overflow_Protection"><a class="permalink" href="#Stack_Overflow_Protection">Stack
  Overflow Protection</a></h2>
<p class="Pp"><span class="Ux">FreeBSD</span> supports stack overflow protection
    using the Stack Smashing Protector (SSP) compiler feature. Stack clash
    protection is also enabled, if supported by the compiler for the given
    architecture. In userland, SSP adds a per-process randomized canary at the
    end of every stack frame which is checked for corruption upon return from
    the function, and stack probing in <code class="Dv">PAGE_SIZE</code> chunks.
    In the kernel, a single randomized canary is used globally except on
    aarch64, which has a <code class="Dv">PERTHREAD_SSP</code>
    <a class="Xr">config(8)</a> option to enable per-thread randomized canaries.
    If stack corruption is detected, then the process aborts to avoid
    potentially malicious execution as a result of the corruption. SSP may be
    enabled or disabled when building <span class="Ux">FreeBSD</span> base with
    the <a class="Xr">src.conf(5)</a> SSP knob.</p>
<p class="Pp">When <var class="Va">WITH_SSP</var> is enabled, which is the
    default, world is built with the
    <code class="Fl">-fstack-protector-strong</code> and
    <code class="Fl">-fstack-clash-protection</code> compiler options. The
    kernel is built with the <code class="Fl">-fstack-protector</code>
  option.</p>
<p class="Pp">In addition to SSP, a &#x201C;FORTIFY_SOURCE&#x201D;
    implementation is supported up to level 2 by defining
    <var class="Va">_FORTIFY_SOURCE</var> to <code class="Dv">1</code> or
    <code class="Dv">2</code> before including any
    <span class="Ux">FreeBSD</span> headers. <span class="Ux">FreeBSD</span>
    world builds can set <var class="Va">FORTIFY_SOURCE</var> in the environment
    or <span class="Pa">/etc/src-env.conf</span> to provide a default value for
    <var class="Va">_FORTIFY_SOURCE</var>. When enabled,
    &#x201C;FORTIFY_SOURCE&#x201D; enables extra bounds checking in various
    functions that accept buffers to be written into. These functions currently
    have extra bounds checking support:</p>
<table class="Bl-column Bd-indent">
  <tr id="bcopy">
    <td><a class="permalink" href="#bcopy"><code class="Fn">bcopy</code></a>()</td>
    <td><a class="permalink" href="#bzero"><code class="Fn" id="bzero">bzero</code></a>()</td>
    <td><a class="permalink" href="#fgets"><code class="Fn" id="fgets">fgets</code></a>()</td>
    <td><a class="permalink" href="#getcwd"><code class="Fn" id="getcwd">getcwd</code></a>()</td>
    <td><a class="permalink" href="#gets"><code class="Fn" id="gets">gets</code></a>()</td>
  </tr>
  <tr id="memcpy">
    <td><a class="permalink" href="#memcpy"><code class="Fn">memcpy</code></a>()</td>
    <td><a class="permalink" href="#memmove"><code class="Fn" id="memmove">memmove</code></a>()</td>
    <td><a class="permalink" href="#memset"><code class="Fn" id="memset">memset</code></a>()</td>
    <td><a class="permalink" href="#read"><code class="Fn" id="read">read</code></a>()</td>
    <td><a class="permalink" href="#readlink"><code class="Fn" id="readlink">readlink</code></a>()</td>
  </tr>
  <tr id="snprintf">
    <td><a class="permalink" href="#snprintf"><code class="Fn">snprintf</code></a>()</td>
    <td><a class="permalink" href="#sprintf"><code class="Fn" id="sprintf">sprintf</code></a>()</td>
    <td><a class="permalink" href="#stpcpy"><code class="Fn" id="stpcpy">stpcpy</code></a>()</td>
    <td><a class="permalink" href="#stpncpy"><code class="Fn" id="stpncpy">stpncpy</code></a>()</td>
    <td><a class="permalink" href="#strcat"><code class="Fn" id="strcat">strcat</code></a>()</td>
  </tr>
  <tr id="strcpy">
    <td><a class="permalink" href="#strcpy"><code class="Fn">strcpy</code></a>()</td>
    <td><a class="permalink" href="#strncat"><code class="Fn" id="strncat">strncat</code></a>()</td>
    <td><a class="permalink" href="#strncpy"><code class="Fn" id="strncpy">strncpy</code></a>()</td>
    <td><a class="permalink" href="#vsnprintf"><code class="Fn" id="vsnprintf">vsnprintf</code></a>()</td>
    <td><a class="permalink" href="#vsprintf"><code class="Fn" id="vsprintf">vsprintf</code></a>()</td>
  </tr>
</table>
<p class="Pp">&#x201C;FORTIFY_SOURCE&#x201D; requires compiler support from
    <a class="Xr">clang(1)</a> or <a class="Xr">gcc(1)</a>, which provide the
    <a class="Xr">__builtin_object_size(3)</a> function that is used to
    determine the bounds of an object. This feature works best at optimization
    levels <code class="Fl">-O1</code> and above, as some object sizes may be
    less obvious without some data that the compiler would collect in an
    optimization pass.</p>
<p class="Pp">Similar to SSP, violating the bounds of an object will cause the
    program to abort in an effort to avoid malicious execution. This effectively
    provides finer-grained protection than SSP for some class of function and
    system calls, along with some protection for buffers allocated as part of
    the program data.</p>
</section>
<section class="Ss">
<h2 class="Ss" id="Supervisor_mode_memory_protection"><a class="permalink" href="#Supervisor_mode_memory_protection">Supervisor
  mode memory protection</a></h2>
<p class="Pp">Certain processors include features that prevent unintended access
    to memory pages accessible to userspace (non-privileged) code, while in a
    privileged mode. One feature prevents execution, intended to mitigate
    exploitation of kernel vulnerabilities from userland. Another feature
    prevents unintended reads from or writes to user space memory from the
    kernel. This also provides effective protection against NULL pointer
    dereferences from kernel. An additional mechanism, Linear Address Space
    Separation (LASS), is available on some amd64 machines. LASS prevents
    user-mode applications from accessing kernel-mode memory, and the kernel
    from unsanctioned access to userspace memory. Unlike page table-based
    permission controls, LASS is based only on address values. As a consequence
    of enforcing this separation in hardware, LASS also provides mitigation
    against certain speculative-execution side-channel attacks.</p>
<table class="Bl-column Bd-indent">
  <tr id="Architecture">
    <td><a class="permalink" href="#Architecture"><b class="Sy">Architecture</b></a></td>
    <td><a class="permalink" href="#Feature"><b class="Sy" id="Feature">Feature</b></a></td>
    <td><a class="permalink" href="#Access"><b class="Sy" id="Access">Access
      Type Prevented</b></a></td>
  </tr>
  <tr>
    <td>amd64</td>
    <td>LASS</td>
    <td>All</td>
  </tr>
  <tr>
    <td>amd64</td>
    <td>SMAP</td>
    <td>Read / Write</td>
  </tr>
  <tr>
    <td>amd64</td>
    <td>SMEP</td>
    <td>Execute</td>
  </tr>
  <tr>
    <td>arm64</td>
    <td>PAN</td>
    <td>Read / Write</td>
  </tr>
  <tr>
    <td>arm64</td>
    <td>PXN</td>
    <td>Execute</td>
  </tr>
  <tr>
    <td>riscv</td>
    <td>SUM</td>
    <td>Read / Write</td>
  </tr>
  <tr>
    <td>riscv</td>
    <td>-</td>
    <td>Execute</td>
  </tr>
</table>
<p class="Pp">Most of these features are automatically used by the kernel, with
    no user-facing configuration. LASS is controlled by the
    <var class="Va">hw.lass</var> loader tunable. It is enabled by default, when
    available.</p>
</section>
<section class="Ss">
<h2 class="Ss" id="Capsicum"><a class="permalink" href="#Capsicum">Capsicum</a></h2>
<p class="Pp">Capsicum is a lightweight OS capability and sandbox framework. See
    <a class="Xr">capsicum(4)</a> for more information.</p>
</section>
</section>
<section class="Sh">
<h1 class="Sh" id="HARDWARE_VULNERABILITY_MITIGATIONS"><a class="permalink" href="#HARDWARE_VULNERABILITY_MITIGATIONS">HARDWARE
  VULNERABILITY MITIGATIONS</a></h1>
<section class="Ss">
<h2 class="Ss" id="Firmware_and_Microcode"><a class="permalink" href="#Firmware_and_Microcode">Firmware
  and Microcode</a></h2>
<p class="Pp">Recent years have seen an unending stream of new hardware
    vulnerabilities, notably CPU ones generally caused by detectable
    microarchitectural side-effects of speculative execution which leak private
    data from some other thread or process or sometimes even internal CPU state
    that is normally inaccessible. Hardware vendors usually address these
    vulnerabilities as they are discovered by releasing microcode updates, which
    may then be bundled into platform firmware updates (historically called BIOS
    updates for PCs) or packages to be updated by the operating system at boot
    time.</p>
<p class="Pp">Platform firmware updates, if available from the manufacturer, are
    the best defense as they provide coverage during early boot. Install them
    with <span class="Pa">sysutils/flashrom</span> from the
    <span class="Ux">FreeBSD</span> Ports Collection.</p>
<p class="Pp">If platform firmware updates are no longer available, packaged
    microcode is available for installation at
    <span class="Pa">sysutils/cpu-microcode</span> and can be loaded at runtime
    using <a class="Xr">loader.conf(5)</a>, see the package message for more
    details.</p>
<p class="Pp">The best defense overall against hardware vulnerabilities is to
    timely apply these updates when available, as early as possible in the boot
    process, and to disable the affected hardware's problematic functionalities
    when possible (e.g., CPU Simultaneous Multi-Threading). Software mitigations
    are only partial substitutes for these, but they can be helpful on
    out-of-support hardware or as complements for just-discovered
    vulnerabilities not yet addressed by vendors. Some software mitigations
    depend on hardware capabilities provided by a microcode update.</p>
</section>
<section class="Ss">
<h2 class="Ss" id="Architectural_Vulnerability_Mitigations"><a class="permalink" href="#Architectural_Vulnerability_Mitigations">Architectural
  Vulnerability Mitigations</a></h2>
<p class="Pp"><span class="Ux">FreeBSD</span>'s usual policy is to apply by
    default all OS-level mitigations that do not require recompilation, except
    those the particular hardware it is running on is known not to be vulnerable
    to (which sometimes requires firmware updates), or those that are extremely
    detrimental to performance in proportion to the protection they actually
    provide. OS-level mitigations generally can have noticeable performance
    impacts on specific workloads. If your threat model allows it, you may want
    to try disabling some of them in order to possibly get better performance.
    Conversely, minimizing the risks may require you to explicitly enable the
    most expensive ones. The description of each vulnerability/mitigation
    indicates whether it is enabled or disabled by default and under which
    conditions. It also lists the knobs to tweak to force a particular
  status.</p>
</section>
<section class="Ss">
<h2 class="Ss" id="Zenbleed"><a class="permalink" href="#Zenbleed">Zenbleed</a></h2>
<p class="Pp">The &#x201C;Zenbleed&#x201D; vulnerability exclusively affects AMD
    processors based on the Zen2 microarchitecture. In contrast with, e.g.,
    Meltdown and the different variants of Spectre, which leak data by leaving
    microarchitectural traces, Zenbleed is a genuine hardware bug affecting the
    CPU's architectural state. With particular sequences of instructions whose
    last ones are mispredicted by speculative execution, it is possible to make
    appear in an XMM register data previously put in some XMM register by some
    preceding or concurrent task executing on the same physical core (disabling
    Simultaneous Multi-Threading (SMT) is thus not a sufficient protection).</p>
<p class="Pp">According to the vulnerability's discoverer, all Zen2-based
    processors are affected (see
    <a class="Lk" href="https://lock.cmpxchg8b.com/zenbleed.html">https://lock.cmpxchg8b.com/zenbleed.html</a>).
    As of August 2023, AMD has not publicly listed any corresponding errata but
    has issued a security bulletin (AMD-SB-7008) entitled &#x201C;Cross-Process
    Information Leak&#x201D; indicating that platform firmware fixing the
    vulnerability will be distributed to manufacturers no sooner than the end of
    2023, except for Rome processors for which it is already available. No
    standalone CPU microcodes have been announced so far. The only
    readily-applicable fix mentioned by the discoverer is to set a bit of an
    undocumented MSR, which reportedly completely stops XMM register leaks.</p>
<p class="Pp"><span class="Ux">FreeBSD</span> currently sets this bit by default
    on all Zen2 processors. In the future, it might set it by default only on
    those Zen2 processors whose microcode has not been updated to revisions
    fixing the vulnerability, once such microcode updates have been actually
    released and community-tested. To this mitigation are associated the
    following knobs:</p>
<dl class="Bl-tag">
  <dt id="machdep.mitigations.zenbleed.enable"><var class="Va">machdep.mitigations.zenbleed.enable</var></dt>
  <dd>A read-write integer tunable and sysctl indicating whether the mitigation
      should be forcibly disabled (0), enabled (1) or if it is left to
      <span class="Ux">FreeBSD</span> to selectively apply it (2). Any other
      integer value is silently converted to and treated as value 2. Note that
      this setting is silently ignored when running on non-Zen2 processors to
      ease applying a common configuration to heterogeneous machines.</dd>
  <dt id="machdep.mitigations.zenbleed.state"><var class="Va">machdep.mitigations.zenbleed.state</var></dt>
  <dd>A read-only string indicating the current mitigation state. It can be
      either &#x201C;Not applicable&#x201D;, if the processor is not Zen2-based,
      &#x201C;Mitigation enabled&#x201D; or &#x201C;Mitigation disabled&#x201D;.
      This state is automatically updated each time the sysctl
      <var class="Va">machdep.mitigations.zenbleed.enable</var> is written to.
      Note that it can become inaccurate if the chicken bit is set or cleared
      directly via <a class="Xr">cpuctl(4)</a> (which includes the
      <a class="Xr">cpucontrol(8)</a> utility).</dd>
</dl>
<p class="Pp">The performance impact and threat models related to these
    mitigations should be considered when configuring and deploying them in a
    <span class="Ux">FreeBSD</span> system.</p>
<p class="Pp">Additional mitigation knobs are listed in the
    <a class="Sx" href="#KNOBS_AND_TWEAKS">KNOBS AND TWEAKS</a> section of
    <a class="Xr">security(7)</a>.</p>
</section>
</section>
<section class="Sh">
<h1 class="Sh" id="SEE_ALSO"><a class="permalink" href="#SEE_ALSO">SEE
  ALSO</a></h1>
<p class="Pp"><a class="Xr">elfctl(1)</a>, <a class="Xr">proccontrol(1)</a>,
    <a class="Xr">rtld(1)</a>, <a class="Xr">mmap(2)</a>,
    <a class="Xr">src.conf(5)</a>, <a class="Xr">sysctl.conf(5)</a>,
    <a class="Xr">security(7)</a>, <a class="Xr">cpucontrol(8)</a>,
    <a class="Xr">sysctl(8)</a></p>
</section>
</div>
<table class="foot">
  <tr>
    <td class="foot-date">January 29, 2025</td>
    <td class="foot-os">FreeBSD 15.0</td>
  </tr>
</table>