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