diff options
Diffstat (limited to 'static/freebsd/man7/mitigations.7 3.html')
| -rw-r--r-- | static/freebsd/man7/mitigations.7 3.html | 451 |
1 files changed, 451 insertions, 0 deletions
diff --git a/static/freebsd/man7/mitigations.7 3.html b/static/freebsd/man7/mitigations.7 3.html new file mode 100644 index 00000000..c261ebf5 --- /dev/null +++ b/static/freebsd/man7/mitigations.7 3.html @@ -0,0 +1,451 @@ +<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> — + <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 “FORTIFY_SOURCE” + 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, + “FORTIFY_SOURCE” 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">“FORTIFY_SOURCE” 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 “Zenbleed” 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 “Cross-Process + Information Leak” 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 “Not applicable”, if the processor is not Zen2-based, + “Mitigation enabled” or “Mitigation disabled”. + 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> |