1.\" Copyright © 2023 The FreeBSD Foundation 2.\" 3.\" This documentation was written by Ed Maste <emaste@freebsd.org>, and 4.\" Olivier Certner <olce.freebsd@certner.fr> at Kumacom SAS, under 5.\" sponsorship of the FreeBSD Foundation. 6.\" 7.\" Redistribution and use in source and binary forms, with or without 8.\" modification, are permitted provided that the following conditions 9.\" are met: 10.\" 1. Redistributions of source code must retain the above copyright 11.\" notice, this list of conditions and the following disclaimer. 12.\" 2. Redistributions in binary form must reproduce the above copyright 13.\" notice, this list of conditions and the following disclaimer in the 14.\" documentation and/or other materials provided with the distribution. 15.\" 16.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND 17.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE 18.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE 19.\" ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE 20.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL 21.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS 22.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) 23.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT 24.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY 25.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF 26.\" SUCH DAMAGE. 27.\" 28.Dd July 23, 2024 29.Dt MITIGATIONS 7 30.Os 31.Sh NAME 32.Nm mitigations 33.Nd FreeBSD Security Vulnerability Mitigations 34.Sh SYNOPSIS 35In 36.Fx , 37various security mitigations are employed to limit the impact of 38vulnerabilities and protect the system from malicious attacks. 39Some of these mitigations have run-time controls to enable them on a global 40or per-process basis, some are optionally enabled or disabled at compile time, 41and some are inherent to the implementation and have no controls. 42.Pp 43The following vulnerability mitigations are covered in this document: 44.Bl -bullet -compact 45.It 46Address Space Layout Randomization (ASLR) 47.It 48Position Independent Executable (PIE) 49.It 50Write XOR Execute page protection policy 51.It 52.Dv PROT_MAX 53.It 54Relocation Read-Only (RELRO) 55.It 56Bind Now 57.It 58Stack Overflow Protection 59.It 60Supervisor Mode Memory Protection 61.It 62Hardware Vulnerability Mitigation Controls 63.It 64Capsicum 65.El 66.Pp 67Please note that the effectiveness and availability of these mitigations may 68vary depending on the 69.Fx 70version and system configuration. 71.Sh DESCRIPTION 72Security vulnerability mitigations are techniques employed in 73.Fx 74to limit the potential impact of security vulnerabilities in software and 75hardware. 76It is essential to understand that mitigations do not directly address the 77underlying security issues. 78They are not a substitute for secure coding practices. 79Mitigations serve as an additional layer of defense, helping to reduce the 80likelihood of a successful exploitation of vulnerabilities by making it 81more difficult for attackers to achieve their objectives. 82.Pp 83This manual page describes the security mitigations implemented in 84.Fx 85to enhance the overall security of the operating system. 86Each mitigation is designed to protect against specific types of attacks 87and vulnerabilities. 88.\" 89.Sh SOFTWARE VULNERABILITY MITIGATIONS 90.Ss Address Space Layout Randomization (ASLR) 91Address Space Layout Randomization (ASLR) is a security mitigation technique 92that works by randomizing the memory addresses where system and application 93code, data, and libraries are loaded, making it more challenging for attackers 94to predict the memory layout and exploit vulnerabilities. 95.Pp 96ASLR introduces randomness into the memory layout during process execution, 97reducing the predictability of memory addresses. 98ASLR is intended to make exploitation more difficult in the event that an 99attacker discovers a software vulnerability, such as a buffer overflow. 100.Pp 101ASLR can be enabled on both a global and per-process basis. 102Global control is provided by a separate set of 103.Xr sysctl 8 104knobs for 32- and 64-bit processes. 105It can be or disabled on a per-process basis via 106.Xr proccontrol 1 . 107Note that an ASLR mode change takes effect upon address space change, 108i.e., upon 109.Xr execve 2 . 110.Pp 111Global controls for 32-bit processes: 112.Bl -tag -width kern.elf32.aslr.pie_enable 113.It Va kern.elf32.aslr.enable 114Enable ASLR for 32-bit ELF binaries, other than Position Independent 115Executable (PIE) binaries. 116.It Va kern.elf32.aslr.pie_enable 117Enable ASLR for 32-bit Position Independent Executable (PIE) ELF binaries. 118.It Va kern.elf32.aslr.honor_sbrk 119Reserve the legacy 120.Xr sbrk 2 121region for compatibility with older binaries. 122.It Va kern.elf32.aslr.stack 123Randomize the stack location for 32-bit ELF binaries. 124.El 125.Pp 126Global controls for 64-bit processes: 127.Bl -tag -width kern.elf64.aslr.pie_enable 128.It Va kern.elf64.aslr.enable 129Enable ASLR for 64-bit ELF binaries, other than Position Independent 130Executable (PIE) binaries. 131.It Va kern.elf64.aslr.pie_enable 132Enable ASLR for 64-bit Position Independent Executable (PIE) ELF binaries. 133.It Va kern.elf64.aslr.honor_sbrk 134Reserve the legacy 135.Xr sbrk 2 136region for compatibility with older binaries. 137.It Va kern.elf64.aslr.stack 138Randomize the stack location for 64-bit ELF binaries. 139.El 140.Pp 141To execute a command with ASLR enabled or disabled: 142.Pp 143proccontrol 144.Fl m Ar aslr 145.Op Fl s Ar enable | disable 146.Ar command 147.\" 148.Ss Position Independent Executable (PIE) 149PIE binaries are executable files that do not have a fixed load address. 150They can be loaded at an arbitrary memory address by the 151.Xr rtld 152run-time linker. 153With ASLR they are loaded at a random address on each execution. 154.\" 155.Ss Write XOR Execute page protection policy 156Write XOR Execute (W^X) is a vulnerability mitigation strategy that strengthens 157the security of the system by controlling memory access permissions. 158.Pp 159Under the W^X mitigation, memory pages may be writable (W) or executable (E), 160but not both at the same time. 161This means that code execution is prevented in areas of memory that are 162designated as writable, and writing or modification of memory is restricted in 163areas marked for execution. 164Applications that perform Just In Time (JIT) compilation need to be adapted 165to be compatible with W^X. 166.Pp 167There are separate 168.Xr sysctl 8 169knobs to control W^X policy enforcement for 32- and 64-bit processes. 170The W^X policy is enabled by setting the appropriate 171.Dv allow_wx 172sysctl to 0. 173.Bl -tag -width kern.elf64.allow_wx 174.It Va kern.elf32.allow_wx 175Allow 32-bit processes to map pages simultaneously writable and executable. 176.It Va kern.elf64.allow_wx 177Allow 64-bit processes to map pages simultaneously writable and executable. 178.El 179.\" 180.Ss PROT_MAX 181.Dv PROT_MAX 182is a FreeBSD-specific extension to 183.Xr mmap 2 . 184.Dv PROT_MAX 185provides the ability to set the maximum protection of a region allocated by 186.Xr mmap 187and later altered by 188.Xr mprotect . 189For example, memory allocated originally with an mmap prot argument of 190PROT_MAX(PROT_READ | PROT_WRITE) | PROT_READ 191may be made writable by a future 192.Xr mprotect 193call, but may not be made executable. 194.\" 195.Ss Relocation Read-Only (RELRO) 196Relocation Read-Only (RELRO) is a mitigation tool that makes certain portions 197of a program's address space that contain ELF metadata read-only, after 198relocation processing by 199.Xr rtld 1 . 200.Pp 201When enabled in isolation the RELRO option provides 202.Em partial RELRO 203support. 204In this case the Procedure Linkage Table (PLT)-related part of the 205Global Offset Table (GOT) (in the section typically named .got.plt) remains 206writable. 207.Pp 208RELRO is enabled by default. 209The 210.Xr src.conf 5 211build-time option 212.Va WITHOUT_RELRO 213may be used to disable it. 214.Ss BIND_NOW 215The 216.Va WITH_BIND_NOW 217.Xr src.conf 5 218build-time option causes binaries to be built with the 219.Dv DF_BIND_NOW 220flag set. 221The run-time loader 222.Xr rtld 1 223will then perform all relocation processing when the process starts, instead of 224on demand (on the first access to each symbol). 225.Pp 226When enabled in combination with 227.Dv RELRO 228(which is enabled by default) this provides 229.Em full RELRO . 230The entire GOT (.got and .got.plt) are made read-only at program startup, 231preventing attacks on the relocation table. 232Note that this results in a nonstandard Application Binary Interface (ABI), 233and it is possible that some applications may not function correctly. 234.\" 235.Ss Stack Overflow Protection 236.Fx 237supports stack overflow protection using the Stack Smashing Protector 238.Pq SSP 239compiler feature. 240In userland, SSP adds a per-process randomized canary at the end of every stack 241frame which is checked for corruption upon return from the function. 242In the kernel, a single randomized canary is used globally except on aarch64, 243which has a 244.Dv PERTHREAD_SSP 245.Xr config 8 246option to enable per-thread randomized canaries. 247If stack corruption is detected, then the process aborts to avoid potentially 248malicious execution as a result of the corruption. 249SSP may be enabled or disabled when building 250.Fx 251base with the 252.Xr src.conf 5 253SSP knob. 254.Pp 255When 256.Va WITH_SSP 257is enabled, which is the default, world is built with the 258.Fl fstack-protector-strong 259compiler option. 260The kernel is built with the 261.Fl fstack-protector 262option. 263.Pp 264In addition to SSP, a 265.Dq FORTIFY_SOURCE 266implementation is supported up to level 2 by defining 267.Va _FORTIFY_SOURCE 268to 269.Dv 1 270or 271.Dv 2 272before including any 273.Fx 274headers. 275.Fx 276world builds can set 277.Va FORTIFY_SOURCE 278in the environment or 279.Pa /etc/src-env.conf 280to provide a default value for 281.Va _FORTIFY_SOURCE . 282When enabled, 283.Dq FORTIFY_SOURCE 284enables extra bounds checking in various functions that accept buffers to be 285written into. 286These functions currently have extra bounds checking support: 287.Bl -column -offset indent "snprintf" "memmove" "strncpy" "vsnprintf" "readlink" 288.It bcopy Ta bzero Ta fgets Ta getcwd Ta gets 289.It memcpy Ta memmove Ta memset Ta read Ta readlink 290.It snprintf Ta sprintf Ta stpcpy Ta stpncpy Ta strcat 291.It strcpy Ta strncat Ta strncpy Ta vsnprintf Ta vsprintf 292.El 293.Pp 294.Dq FORTIFY_SOURCE 295requires compiler support from 296.Xr clang 1 297or 298.Xr gcc 1 , 299which provide the 300.Xr __builtin_object_size 3 301function that is used to determine the bounds of an object. 302This feature works best at optimization levels 303.Fl O1 304and above, as some object sizes may be less obvious without some data that the 305compiler would collect in an optimization pass. 306.Pp 307Similar to SSP, violating the bounds of an object will cause the program to 308abort in an effort to avoid malicious execution. 309This effectively provides finer-grained protection than SSP for some class of 310function and system calls, along with some protection for buffers allocated as 311part of the program data. 312.\" 313.Ss Supervisor mode memory protection 314Certain processors include features that prevent unintended access to memory 315pages accessible to userspace (non-privileged) code, while in a privileged 316mode. 317One feature prevents execution, intended to mitigate exploitation of kernel 318vulnerabilities from userland. 319Another feature prevents unintended reads from or writes to user space memory 320from the kernel. 321This also provides effective protection against NULL pointer dereferences from 322kernel. 323.Bl -column -offset indent "Architecture" "Feature" "Access Type Prevented" 324.It Sy Architecture Ta Sy Feature Ta Sy Access Type Prevented 325.It amd64 Ta SMAP Ta Read / Write 326.It amd64 Ta SMEP Ta Execute 327.It arm64 Ta PAN Ta Read / Write 328.It arm64 Ta PXN Ta Execute 329.It riscv Ta SUM Ta Read / Write 330.It riscv Ta - Ta Execute 331.El 332.Pp 333These features are automatically used by the kernel. 334There is no user-facing configuration. 335.Ss Hardware vulnerability controls 336See 337.Xr security 7 338for more information. 339.\" 340.Ss Capsicum 341Capsicum is a lightweight OS capability and sandbox framework. 342See 343.Xr capsicum 4 344for more information. 345.Pp 346.Sh HARDWARE VULNERABILITY MITIGATIONS 347Recent years have seen an unending stream of new hardware vulnerabilities, 348notably CPU ones generally caused by detectable microarchitectural side-effects 349of speculative execution which leak private data from some other thread or 350process or sometimes even internal CPU state that is normally inaccessible. 351Hardware vendors usually address these vulnerabilities as they are discovered by 352releasing microcode updates, which may then be bundled into platform firmware 353updates 354.Pq historically called BIOS updates for PCs . 355.Pp 356The best defense overall against hardware vulnerabilities is to timely apply 357these updates when available and to disable the affected hardware's problematic 358functionalities when possible (e.g., CPU Simultaneous Multi-Threading). 359Software mitigations are only partial substitutes for these, but they can be 360helpful on out-of-support hardware or as complements for just-discovered 361vulnerabilities not yet addressed by vendors. 362Some software mitigations depend on hardware capabilities provided by a 363microcode update. 364.Pp 365FreeBSD's usual policy is to apply by default all OS-level mitigations that do 366not require recompilation, except those the particular hardware it is running on 367is known not to be vulnerable to 368.Pq which sometimes requires firmware updates , 369or those that are extremely detrimental to performance in proportion to the 370protection they actually provide. 371OS-level mitigations generally can have noticeable performance impacts on 372specific workloads. 373If your threat model allows it, you may want to try disabling some of them in 374order to possibly get better performance. 375Conversely, minimizing the risks may require you to explicitly enable the most 376expensive ones. 377The description of each vulnerability/mitigation indicates whether it is enabled 378or disabled by default and under which conditions. 379It also lists the knobs to tweak to force a particular status. 380.Ss Zenbleed 381The 382.Dq Zenbleed 383vulnerability exclusively affects AMD processors based on the Zen2 384microarchitecture. 385In contrast with, e.g., Meltdown and the different variants of Spectre, which 386leak data by leaving microarchitectural traces, Zenbleed is a genuine hardware 387bug affecting the CPU's architectural state. 388With particular sequences of instructions whose last ones are mispredicted by 389speculative execution, it is possible to make appear in an XMM register data 390previously put in some XMM register by some preceding or concurrent task 391executing on the same physical core 392.Po disabling Simultaneous Muti-Threading 393.Pq SMT 394is thus not a sufficient protection 395.Pc . 396.Pp 397According to the vulnerability's discoverer, all Zen2-based processors are 398affected 399.Po see 400.Lk https://lock.cmpxchg8b.com/zenbleed.html 401.Pc . 402As of August 2023, AMD has not publicly listed any corresponding errata but has 403issued a security bulletin 404.Pq AMD-SB-7008 405entitled 406.Dq Cross-Process Information Leak 407indicating that platform firmware fixing the vulnerability will be distributed 408to manufacturers no sooner than the end of 2023, except for Rome processors for 409which it is already available. 410No standalone CPU microcodes have been announced so far. 411The only readily-applicable fix mentioned by the discoverer is to set a bit of 412an undocumented MSR, which reportedly completely stops XMM register leaks. 413.Pp 414.Fx 415currently sets this bit by default on all Zen2 processors. 416In the future, it might set it by default only on those Zen2 processors whose 417microcode has not been updated to revisions fixing the vulnerability, once such 418microcode updates have been actually released and community-tested. 419To this mitigation are associated the following knobs: 420.Bl -tag -width indent 421.It Va machdep.mitigations.zenbleed.enable 422A read-write integer tunable and sysctl indicating whether the mitigation should 423be forcibly disabled (0), enabled (1) or if it is left to 424.Fx 425to selectively apply it (2). 426Any other integer value is silently converted to and treated as value 2. 427Note that this setting is silently ignored when running on non-Zen2 processors 428to ease applying a common configuration to heterogeneous machines. 429.It Va machdep.mitigations.zenbleed.state 430A read-only string indicating the current mitigation state. 431It can be either 432.Dq Not applicable , 433if the processor is not Zen2-based, 434.Dq Mitigation enabled 435or 436.Dq Mitigation disabled . 437This state is automatically updated each time the sysctl 438.Va machdep.mitigations.zenbleed.enable 439is written to. 440Note that it can become inaccurate if the chicken bit is set or cleared 441directly via 442.Xr cpuctl 4 443.Po which includes the 444.Xr cpucontrol 8 445utility 446.Pc . 447.El 448.Pp 449The performance impact and threat models related to these mitigations 450should be considered when configuring and deploying them in a 451.Fx 452system. 453.Pp 454.Sh SEE ALSO 455.Xr elfctl 1 , 456.Xr proccontrol 1 , 457.Xr rtld 1 , 458.Xr mmap 2 , 459.Xr src.conf 5 , 460.Xr sysctl.conf 5 , 461.Xr security 7 , 462.Xr cpucontrol 8 , 463.Xr sysctl 8 464