aboutsummaryrefslogtreecommitdiff
path: root/sys/amd64
Commit message (Collapse)AuthorAgeFilesLines
* pkru: Fix handling of 1GB largepage mappingsMark Johnston2026-04-212-12/+51
| | | | | | | | | | | | | | pmap_pkru_update_range() did not handle the case where a PDPE has PG_PS set. More generally, the SET_PKRU and CLEAR_PKRU sysarch implementations did not check whether the request covers a "boundary" vm map entry. Fix this, add the missing PG_PS test, and add some tests. Approved by: so Security: FreeBSD-SA-26:11.amd64 Security: CVE-2026-6386 Reported by: Nicholas Carlini <npc@anthropic.com> Reviewed by: kib, alc Differential Revision: https://reviews.freebsd.org/D56184
* amd64/conf: Remove a config committed by accidentMark Johnston2026-02-091-5/+0
| | | | | | | Reported by: kib, kp Fixes: 350ba9672a7f ("unix: Set O_RESOLVE_BENEATH on fds transferred between jails") (cherry picked from commit 3ef39f58e5d63a78fd1c37e6c62d599bc68d5e1e)
* unix: Set O_RESOLVE_BENEATH on fds transferred between jailsMark Johnston2026-02-091-0/+5
| | | | | | | | | | | | | | | | | | | | | | If a pair of jails with different filesystem roots is able to exchange SCM_RIGHTS messages (e.g., using a unix socket in a shared nullfs mount), a process in one jail can open a directory outside of the root of the second jail and then pass the fd to that second jail, allowing the receiving process to escape the jail chroot. Address this using the new FD_RESOLVE_BENEATH flag. When externalizing an SCM_RIGHTS message into the receiving process, automatically set this flag on all new fds where a jail boundary is crossed. This ensures that the receiver cannot do more than access files underneath the directory; in particular, the received fd cannot be used to access vnodes not accessible by the sender. PR: 262179 Reviewed by: kib MFC after: 3 weeks Differential Revision: https://reviews.freebsd.org/D50371 (cherry picked from commit 350ba9672a7f4f16e30534a603df577dfd083b3f)
* vmm: Emulate testb imm8,r/m8Jose Luis Duran2025-03-111-0/+12
| | | | | | | | | | | | | | Add support for "testb imm8,r/m8" emulation. PR: 261940 PR: 282852 Reviewed by: markj, emaste Approved by: emaste (mentor) Obtained from: Illumos (https://www.illumos.org/issues/14483) MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D49208 (cherry picked from commit 49a4838a0d94e145a826abf02aa03ff444e614e3)
* x86 atomics: Remove unused WANT_FUNCTIONSOlivier Certner2025-01-171-3/+0
| | | | | | | | | | | | This macro has not been in use since commit "inline atomics and allow tied modules to inline locks" (r335873, f4b3640475cec929). Reviewed by: markj, kib, emaste, imp MFC after: 5 days Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D48061 (cherry picked from commit fa368cc86cebe7185b3a99d4f6083033da377eee)
* atomics: Constify loadsOlivier Certner2025-01-171-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | In order to match reality, allow using these functions with pointers on const objects, and bring us closer to C11. Remove the '+' modifier in the atomic_load_acq_64_i586()'s inline asm statement's constraint for '*p' (the value to load). CMPXCHG8B always writes back some value, even when the value exchange does not happen in which case what was read is written back. atomic_load_acq_64_i586() further takes care of the operation atomically writing back the same value that was read in any case. All in all, this makes the inline asm's write back undetectable by any other code, whether executing on other CPUs or code on the same CPU before and after the call to atomic_load_acq_64_i586(), except for the fact that CMPXCHG8B will trigger a #GP(0) if the memory address is part of a read-only mapping. This unfortunate property is however out of scope of the C abstract machine, and in particular independent of whether the 'uint64_t' pointed to is declared 'const' or not. Approved by: markj (mentor) MFC after: 5 days Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D46887 (cherry picked from commit 5e9a82e898d55816c366cfa3ffbca84f02569fe5)
* x86: Remove invalid DEVMETHOD methods for leaf devicesJohn Baldwin2024-11-301-4/+0
| | | | | | | | | | | None of these drivers are for bus devices, so bus_generic_* is not appropriate. Most of these were nops except that detach would actually "succeed" (but not do any cleanup). Reviewed by: imp Differential Revision: https://reviews.freebsd.org/D47374 (cherry picked from commit df615735960370255d3acc4ac2a6f4fd297b7461)
* amd64: Use bool for booleans in getmemsizeJohn Baldwin2024-11-291-9/+10
| | | | | | | Reviewed by: markj Differential Revision: https://reviews.freebsd.org/D43693 (cherry picked from commit 70539d5da600a65d34c8d965ef2a9d475cbc9c4e)
* vmm: avoid potential KASSERT kernel panic in vm_handle_dbPierre Pronchery2024-10-061-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | If the guest VM emits the exit code VM_EXITCODE_DB the kernel will execute the function named vm_handle_db. If the value of rsp is not page aligned and if rsp+sizeof(uint64_t) spans across two pages, the function vm_copy_setup will need two structs vm_copyinfo to prepare the copy operation. For instance is rsp value is 0xFFC, two vm_copyinfo objects are needed: * address=0xFFC, len=4 * address=0x1000, len=4 The vulnerability was addressed by commit 51fda658baa ("vmm: Properly handle writes spanning across two pages in vm_handle_db"). Still, replace the KASSERT with an error return as a more defensive approach. Reported by: Synacktiv Reviewed by markj, emaste Security: HYP-09 Sponsored by: The Alpha-Omega Project Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D46133 (cherry picked from commit d19fa9c1b72bc52e51524abcc59ad844012ec365) (cherry picked from commit f8db6fb90e739293d6d72310fa554ede072f8232)
* bhyve: initialize register valuePierre Pronchery2024-09-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | In case of an error in a code pattern like ``` uint64_t val; error = memread(vcpu, gpa, &val, 1, arg); error = vie_update_register(vcpu, reg, val, size); ``` uninitialized stack data would be used. Reported by: Synacktiv Reviewed by: markj Security: HYP-21 Sponsored by: The Alpha-Omega Project Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D46107 (cherry picked from commit 94693ec7c85363f9b0098247489cea3efdb183f9) (cherry picked from commit a03acfa43410b3a449fa8d5b1dbba20e0bf02d5a)
* amd64 GENERIC: Switch uart hints from "isa" to "acpi"John Baldwin2024-07-231-4/+2
| | | | | | | | | | | | | | | | | | This causes these hints to be only used to wire device unit numbers for serial ports enumerated by ACPI but will not create ISA device nodes if ACPI doesn't enumerate them. Note that IRQ hints are not used for wiring so have been removed. PR: 270707 Reported by: aixdroix_OSS@protonmail.com, Michael Dexter Reported by: mfw_burn@pm.me, Hannes Hfauswedell <h2+fbsdports@fsfe.org> Reported by: Matthias Lanter <freebsd@lanter-it.ch> Reported by: William Bulley <web@umich.edu> Reviewed by: imp MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D45945 (cherry picked from commit 9cc06bf7aa2846c35483de567779bb8afc289f53)
* amd64 GENERIC: Drop hints for fdc0 and ppc0John Baldwin2024-07-231-10/+0
| | | | | | | | | | Modern x86 systems do not ship with ISA floppy disk controllers or LPT ports. Reviewed by: imp Differential Revision: https://reviews.freebsd.org/D45946 (cherry picked from commit 480cc750a2a8f92d078803f15eecb1f8a084a1ea)
* Adjust comments referencing vm_mem_init()Mitchell Horne2024-06-061-3/+4
| | | | | | | | | | | I cannot find a time where the function was not named this. Reviewed by: kib, markj MFC after: 3 days Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D45383 (cherry picked from commit deab57178f0b06eab56d7811674176985a8ea98d)
* vmm(4): Fix a typo in a kernel messageGordon Bergling2024-04-281-1/+1
| | | | | | - s/cant/can't/ (cherry picked from commit 8b5c5cae92d5b44f03636540a787fd6e994ce816)
* Stop using expressions in _Alignof()Minsoo Choo2024-04-081-1/+2
| | | | | | | | | | | | | _Alignof(expression) is a non-standard extension. This is not allowed in gnu11 and gnu17 which follow the C11 standard _Alignof(type). Reviewed by: arichardson, imp, jhb Fixes: 4a9cd9fc22d7 amd64 db_trace: Reject unaligned frame pointers Fixes: 7ccaf76a27f1 riscv db_trace: Ensure trapframe pointer is suitably aligned. Fixes: 638c68897fbd arm64 db_trace: Ensure trapframe pointer is suitably aligned. Differential Revision: https://reviews.freebsd.org/D43409 (cherry picked from commit 03d04bf49492fc70366e6d78194336a4122282a2)
* x86: handle MXCSR from XSAVEOPT when x87 state was optimizedKonstantin Belousov2024-04-021-0/+21
| | | | | | PR: 275322 (cherry picked from commit 1c091d11261a3c8cc3728b92760e65242c0f5949)
* x86: test the right CPUID bit when checking for XSAVEOPT supportKonstantin Belousov2024-04-021-1/+4
| | | | (cherry picked from commit 960d151eaa1ecde109accc30ca0c3306551d8e58)
* rdmsr_safe/wrmsr_safe: handle pcb_onfault nestingAndriy Gapon2024-02-171-5/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | rdmsr_safe and wrmsr_safe can be called while pcb_onfault is already set, so the functions are modified to preserve the handler rather than resetting it before returning. One case where that happens is when AMD microcode update routine is executed on a stack where copyin / copyout was already active. Here is a sample panic message from a crash caused by resetting the handler: <118>Updating CPU Microcode... Fatal trap 12: page fault while in kernel mode cpuid = 3; apic id = 03 fault virtual address = 0x11ed0de6000 fault code = supervisor write data, page not present instruction pointer = 0x20:0xffffffff80c2df03 stack pointer = 0x28:0xfffffe01ce4a4c70 frame pointer = 0x28:0xfffffe01ce4a4c70 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 117 (logger) trap number = 12 panic: page fault cpuid = 3 time = 1681462027 KDB: stack backtrace: db_trace_self_wrapper() at 0xffffffff80615deb = db_trace_self_wrapper+0x2b/frame 0xfffffe01ce4a4830 kdb_backtrace() at 0xffffffff80943c77 = kdb_backtrace+0x37/frame 0xfffffe01ce4a48e0 vpanic() at 0xffffffff808f5fe5 = vpanic+0x185/frame 0xfffffe01ce4a4940 panic() at 0xffffffff808f5da3 = panic+0x43/frame 0xfffffe01ce4a49a0 trap_fatal() at 0xffffffff80c31849 = trap_fatal+0x379/frame 0xfffffe01ce4a4a00 trap_pfault() at 0xffffffff80c318b5 = trap_pfault+0x65/frame 0xfffffe01ce4a4a60 trap() at 0xffffffff80c30f5f = trap+0x29f/frame 0xfffffe01ce4a4b80 trap_check() at 0xffffffff80c31c29 = trap_check+0x29/frame 0xfffffe01ce4a4ba0 calltrap() at 0xffffffff80c07fd8 = calltrap+0x8/frame 0xfffffe01ce4a4ba0 --- trap 0xc, rip = 0xffffffff80c2df03, rsp = 0xfffffe01ce4a4c70, rbp = 0xfffffe01ce4a4c70 --- copyout_nosmap_std() at 0xffffffff80c2df03 = copyout_nosmap_std+0x63/frame 0xfffffe01ce4a4c70 uiomove_faultflag() at 0xffffffff8095f0d5 = uiomove_faultflag+0xe5/frame 0xfffffe01ce4a4cb0 uiomove() at 0xffffffff8095efeb = uiomove+0xb/frame 0xfffffe01ce4a4cc0 pipe_read() at 0xffffffff80968860 = pipe_read+0x230/frame 0xfffffe01ce4a4d30 dofileread() at 0xffffffff809653cb = dofileread+0x8b/frame 0xfffffe01ce4a4d80 sys_read() at 0xffffffff80964fa0 = sys_read+0xc0/frame 0xfffffe01ce4a4df0 amd64_syscall() at 0xffffffff80c3221a = amd64_syscall+0x18a/frame 0xfffffe01ce4a4f30 fast_syscall_common() at 0xffffffff80c088eb = fast_syscall_common+0xf8/frame 0xfffffe01ce4a4f30 --- syscall (3, FreeBSD ELF64, read), rip = 0x11ece41cfaa, rsp = 0x11ecbec4908, rbp = 0x11ecbec4920 --- Uptime: 41s And another one: Fatal trap 12: page fault while in kernel mode cpuid = 4; apic id = 04 fault virtual address = 0x800a22000 fault code = supervisor write data, page not present instruction pointer = 0x20:0xffffffff80b2c7ca stack pointer = 0x28:0xfffffe01c55b5480 frame pointer = 0x28:0xfffffe01c55b5480 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 68418 (pfctl) trap number = 12 panic: page fault cpuid = 4 time = 1625184463 KDB: stack backtrace: db_trace_self_wrapper() at 0xffffffff805c1e8b = db_trace_self_wrapper+0x2b/frame 0xfffffe01c55b5040 kdb_backtrace() at 0xffffffff808874b7 = kdb_backtrace+0x37/frame 0xfffffe01c55b50f0 vpanic() at 0xffffffff808449d8 = vpanic+0x188/frame 0xfffffe01c55b5150 panic() at 0xffffffff808445f3 = panic+0x43/frame 0xfffffe01c55b51b0 trap_fatal() at 0xffffffff80b300a5 = trap_fatal+0x375/frame 0xfffffe01c55b5210 trap_pfault() at 0xffffffff80b30180 = trap_pfault+0x80/frame 0xfffffe01c55b5280 trap() at 0xffffffff80b2f729 = trap+0x289/frame 0xfffffe01c55b5390 trap_check() at 0xffffffff80b304d9 = trap_check+0x29/frame 0xfffffe01c55b53b0 calltrap() at 0xffffffff80b0bb28 = calltrap+0x8/frame 0xfffffe01c55b53b0 --- trap 0xc, rip = 0xffffffff80b2c7ca, rsp = 0xfffffe01c55b5480, rbp = 0xfffffe01c55b5480 --- copyout_nosmap_std() at 0xffffffff80b2c7ca = copyout_nosmap_std+0x15a/frame 0xfffffe01c55b5480 pfioctl() at 0xffffffff85539358 = pfioctl+0x4d28/frame 0xfffffe01c55b5940 devfs_ioctl() at 0xffffffff807176cf = devfs_ioctl+0xcf/frame 0xfffffe01c55b59a0 VOP_IOCTL_APV() at 0xffffffff80bb26e2 = VOP_IOCTL_APV+0x92/frame 0xfffffe01c55b59c0 VOP_IOCTL() at 0xffffffff80928014 = VOP_IOCTL+0x34/frame 0xfffffe01c55b5a10 vn_ioctl() at 0xffffffff80923330 = vn_ioctl+0xc0/frame 0xfffffe01c55b5b00 devfs_ioctl_f() at 0xffffffff80717bbe = devfs_ioctl_f+0x1e/frame 0xfffffe01c55b5b20 fo_ioctl() at 0xffffffff808abc6b = fo_ioctl+0xb/frame 0xfffffe01c55b5b30 kern_ioctl() at 0xffffffff808abc01 = kern_ioctl+0x1d1/frame 0xfffffe01c55b5b80 sys_ioctl() at 0xffffffff808ab982 = sys_ioctl+0x132/frame 0xfffffe01c55b5c50 syscallenter() at 0xffffffff80b30cc9 = syscallenter+0x159/frame 0xfffffe01c55b5ca0 amd64_syscall() at 0xffffffff80b309a5 = amd64_syscall+0x15/frame 0xfffffe01c55b5d30 fast_syscall_common() at 0xffffffff80b0c44e = fast_syscall_common+0xf8/frame 0xfffffe01c55b5d30 PR: 276426 Reviewed by: kib, markj MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D43639 (cherry picked from commit 486b265a8fb6b2aad37f2819fa04feacf8184d53)
* amd64 pcb.h: use 4 hex digits for pcb flagsKonstantin Belousov2024-02-141-8/+8
| | | | (cherry picked from commit 5f7ac491eef4994b23b4de250927a85c69a64a31)
* amd64 gdt_segs: use designated initializersKonstantin Belousov2024-02-141-26/+26
| | | | (cherry picked from commit 1d6230b07ff29b4d3ae527dbc0fc3f9775a7542a)
* amd64/linux*: mark brandlists as staticKonstantin Belousov2024-02-142-2/+2
| | | | (cherry picked from commit be707ee09556a3fa345bc30c04aeeaa2a5d2efa2)
* amd64 uprintf_signal: add space between %rax value and code bytesKonstantin Belousov2024-02-141-1/+1
| | | | (cherry picked from commit 130bad217bd8bbd7531539e4f5eb83d3c284e991)
* x86: Adjust base addr for PCI MCFG regionsColin Percival2024-01-181-1/+1
| | | | | | | | | | | | | | | | Each bus gets 1 MB of address space; the actual base address for an MCFG bus range is the address from the table plus the starting bus number times 1 MB. The PCI spec is unclear on this point, but this change matches what Linux does, which is likely enough of a de facto standard regardless of what any de jure standard might attempt to say. Fixes: f54a3890b1f4 ("x86: Support multiple PCI MCFG regions") Reviewed by: jhb Differential Revision: https://reviews.freebsd.org/D43206 (cherry picked from commit 61e2161367bb4e68e603f53b1107f9427f988861)
* x86: Support multiple PCI MCFG regionsJohn Baldwin2024-01-181-38/+84
| | | | | | | | | | | | | In particular, this enables support for PCI config access for domains (segments) other than 0. Reported by: cperciva Tested by: cperciva (m7i.metal-48xl AWS instance) Reviewed by: imp Relnotes: yes Differential Revision: https://reviews.freebsd.org/D42828 (cherry picked from commit f54a3890b1f419d4a9edc99000efef52b9071b8f)
* x86: Refactor pcie_cfgregopenJohn Baldwin2024-01-181-18/+25
| | | | | | | | | | | Split out some bits of pcie_cfgregopen that only need to be executed once into helper functions in preparation for supporting multiple MCFG entries. Reviewed by: imp Differential Revision: https://reviews.freebsd.org/D42829 (cherry picked from commit 9893a4fd31fa4b2e19a7b9cf786f49b9de50b407)
* pci_cfgreg: Add shims to preserve ABI of pci_cfgreg(read|write)John Baldwin2024-01-181-3/+24
| | | | | | | | | | | | | This is a direct commit to stable/14 to preserve the ABI of the the pci_cfgregread and pci_cfgregwrite functions. The new routines are renamed to add a _domain suffix and macros map the new API to the new functions. Note: No API compatibility has been provided as modules in ports should not be using this internal API (normal PCI drivers use pci_read_config and pci_write_config with a device_t). (cherry picked from commit b5d2a06b2c4f50fd20774928602a3b5f0f27b127)
* pci_cfgreg: Add a PCI domain argument to the low-level register APIJohn Baldwin2024-01-183-29/+38
| | | | | | | | | | | | | | | | | | | | | | | | | This commit changes the API of pci_cfgreg(read|write) to add a domain argument (referred to as a segment in ACPI parlance) (note that this is not the same as a NUMA domain, but something PCI-specific). This does not yet enable access to domains other than 0, but updates the API to support domains. Places that use hard-coded bus/slot/function addresses have been updated to hardcode a domain of 0. A few places that have the PCI domain (segment) available such as the acpi_pcib_acpi.c Host-PCI bridge driver pass the PCI domain. The hpt27xx(4) and hptnr(4) drivers fail to attach to a device not on domain 0 since they provide APIs to their binary blobs that only permit bus/slot/function addressing. The x86 non-ACPI PCI bus drivers all hardcode a domain of 0 as they do not support multiple domains. Reviewed by: imp Differential Revision: https://reviews.freebsd.org/D42827 (cherry picked from commit 1587a9db92c03c738bb3f0fc5874b43c961e7c99)
* sys/*/conf/*, docs: fix links to handbookCeri Davies2024-01-103-3/+3
| | | | | | | | | | | | While here, fix all links to older en_US.ISO8859-1 documentation in the src/ tree. PR: 255026 Reported by: Michael Büker <freebsd@michael-bueker.de> Reviewed by: dbaio Differential Revision: https://reviews.freebsd.org/D30265 (cherry picked from commit c1a148873d6488f1dac1cfb207a5927cef89888e)
* thread: Add a return value to cpu_set_upcall()Mark Johnston2024-01-021-7/+12
| | | | | | | | | | | | | | Some implementations copy data to userspace, an operation which can in principle fail. In preparation for adding a __result_use_check annotation to copyin() and related functions, let implementations of cpu_set_upcall() return an error, and check for errors when copying data to user memory. Reviewed by: kib, jhb MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D43100 (cherry picked from commit 7b68fb5ab2a276ccd081cc1a43cebf0fb315e952)
* vmm.h: remove dup declarationKonstantin Belousov2023-12-251-2/+0
| | | | (cherry picked from commit 7c8f16318499d2b05e916abd66148e5409284a9d)
* x86: AMD Zen2: Zenbleed chicken bit mitigationOlivier Certner2023-12-213-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Applies only to bare-metal Zen2 processors. The system currently automatically applies it to all of them. Tunable/sysctl 'machdep.mitigations.zenbleed.enable' can be used to forcibly enable or disable the mitigation at boot or run-time. Possible values are: 0: Mitigation disabled 1: Mitigation enabled 2: Run the automatic determination. Currently, value 2 is the default and has identical effect as value 1. This might change in the future if we choose to take into account microcode revisions in the automatic determination process. The tunable/sysctl value is simply ignored on non-applicable CPU models, which is useful to apply the same configuration on a set of machines that do not all have Zen2 processors. Trying to set it to any integer value not listed above is silently equivalent to setting it to value 2 (automatic determination). The current mitigation state can be queried through sysctl 'machdep.mitigations.zenbleed.state', which returns "Not applicable", "Mitigation enabled" or "Mitigation disabled". Note that this state is not guaranteed to be accurate in case of intervening modifications of the corresponding chicken bit directly via cpuctl(4) (this includes the cpucontrol(8) utility). Resetting the desired policy through 'machdep.mitigations.zenbleed.enable' (possibly to its current value) will reset the hardware state and ensure that the reported state is again coherent with it. Reviewed by: kib Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D41817 (cherry picked from commit ebaea1bcd2eb0aa90937637ed305184b6fedc69b) Approved by: markj (mentor)
* Add cpu_sync_core()Konstantin Belousov2023-10-261-0/+21
| | | | (cherry picked from commit 74ccb8ecf6c115a79f008bc32d4981f1126b63a8)
* add pmap_active_cpus()Konstantin Belousov2023-10-261-0/+6
| | | | (cherry picked from commit 8882b7852acf2588d87ccb6d4c6bf7694511fc56)
* amd64: Remove a stale comment from cpu_setregsJohn Baldwin2023-10-241-4/+0
| | | | | | | Reviewed by: kib, markj, emaste Differential Revision: https://reviews.freebsd.org/D42134 (cherry picked from commit e839ebfc0dc5851d383ac38740f32e96f7bd5186)
* uiomove: Add some assertionsMark Johnston2023-10-241-0/+6
| | | | | | | | | | | | | Make sure that we don't try to copy with a negative resid. Make sure that we don't walk off the end of the iovec array. Reviewed by: kib MFC after: 1 week Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D42098 (cherry picked from commit 8fd0ec53deaad34383d4b344714b74d67105b258)
* amd64 pmap: Prefer consistent naming for loader tunableZhenlei Huang2023-10-241-0/+3
| | | | | | | | | | | | | | | | | | | | The sysctl knob 'vm.pmap.allow_2m_x_ept' is loader tunable and have public document entry in security(7) but is fetched from kernel environment 'hw.allow_2m_x_ept'. That is inconsistent and obscure. As there is public security advisory FreeBSD-SA-19:25.mcepsc [1], people may refer to it and use 'hw.allow_2m_x_ept', let's keep old name for compatibility. [1] https://www.freebsd.org/security/advisories/FreeBSD-SA-19:25.mcepsc.asc Reviewed by: kib Fixes: c08973d09c95 Workaround for Intel SKL002/SKL012S errata MFC after: 3 days Differential Revision: https://reviews.freebsd.org/D42311 (cherry picked from commit 9e7f349ff10691c2e3fb03898dbc942794a47566) (cherry picked from commit 8784b153a31fc0b3a12449a2f0377eb038e6fb7b)
* vmx: Prefer consistent naming for loader tunablesZhenlei Huang2023-10-241-5/+27
| | | | | | | | | | | | | | | | | | | | | | | | | The following loader tunables do have corresponding sysctl MIBs but with different names. That may be historical reason. Let's prefer consistent naming for them so that it will be easier to read and maintain. 1. hw.vmm.l1d_flush -> hw.vmm.vmx.l1d_flush 2. hw.vmm.l1d_flush_sw -> hw.vmm.vmx.l1d_flush_sw 3. hw.vmm.vmx.use_apic_pir -> hw.vmm.vmx.cap.posted_interrupts 4. hw.vmm.vmx.use_apic_vid -> hw.vmm.vmx.cap.virtual_interrupt_delivery 5. hw.vmm.vmx.use_tpr_shadowing -> hw.vmm.vmx.cap.tpr_shadowing Old names are kept for compatibility. Meanwhile, add sysctl flag CTLFLAG_TUN to them so that `sysctl -T` will report them correctly. Reviewed by: corvink, jhb, kib, #bhyve MFC after: 5 days Differential Revision: https://reviews.freebsd.org/D42251 (cherry picked from commit f3ff0918ffcdbcb4c39175f3f9be70999edb14e8) (cherry picked from commit 9e48b627aed346bf5e950134a581218d3097eb7c)
* amd64: Fix two typos of loader tunablesZhenlei Huang2023-10-211-2/+2
| | | | | | | | | | | | | | To match the sysctl MIBs and document entries in security(7). Fixes: 2dec2b4a34b4 amd64: flush L1 data cache on syscall return with an error Fixes: 17edf152e556 Control for Special Register Buffer Data Sampling mitigation Reviewed by: kib MFC after: 1 day Differential Revision: https://reviews.freebsd.org/D42249 (cherry picked from commit afbb8041a0633c97acb51ac895c9ae3cde4fe540) (cherry picked from commit 032a0b44541ffb669a4553105c6f6343ab4e3a67)
* amd64 db_trace: Reject unaligned frame pointersJohn Baldwin2023-10-111-58/+67
| | | | | | | | | | Switch to using db_addr_t to hold frame pointer values until they are verified to be suitably aligned. Reviewed by: kib, markj Differential Revision: https://reviews.freebsd.org/D41532 (cherry picked from commit 4a9cd9fc22d7f87a27ccd3d41b93a0356cd7061c)
* efirt_machdep.c: Trim some unused includesJohn Baldwin2023-10-111-3/+0
| | | | | | | Reviewed by: imp, kib, markj Differential Revision: https://reviews.freebsd.org/D41596 (cherry picked from commit d1e4c63d9e93b113f7ef5aef5e0e79a4d7dca144)
* efirt: Move comment about fpu_kern_enter to where it is calledJohn Baldwin2023-10-111-5/+0
| | | | | | | Reviewed by: imp, kib, andrew, markj Differential Revision: https://reviews.freebsd.org/D41576 (cherry picked from commit 8173fa60ddb7e9a805dec9fef7bf07e74ae4144d)
* x86: Add defines for workaround bits in AMD's MSR "Decode Configuration"Olivier Certner2023-10-101-2/+3
| | | | | | | | | | | | | They are a bit more informative than raw hexadecimal values. While here, sort existing defines of bits for AMD MSRs to match the address order. Reviewed by: kib, emaste Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D41816 (cherry picked from commit 125bbadf6084ac341673c9eb1979a740d3d5899a)
* linuxolator: fix nosys() to not send SIGSYSKonstantin Belousov2023-10-092-2/+2
| | | | (cherry picked from commit 7acc4240ce00af540093b47ad00be0508310b515)
* sysentvec: add SV_SIGSYS flagKonstantin Belousov2023-10-091-2/+4
| | | | (cherry picked from commit b82b4ae752501469053979393e33bbfa74fbc9d2)
* syscalls: fix missing SIGSYS for several ENOSYS errorsKonstantin Belousov2023-10-092-2/+2
| | | | (cherry picked from commit 39024a89146902ca9aba250130b828ad9aced99d)
* amd64 cpu_fetch_syscall_args_fallback(): fix whitespaceKonstantin Belousov2023-10-091-5/+5
| | | | (cherry picked from commit 6b3bb233cd0c3eeeb70e388a62b142b4f22b62b2)
* vmm: Fix VM_GET_CPUS compatibilityMark Johnston2023-08-241-2/+5
| | | | | | | | | | | | | | | | | | bhyve in a 13.x jail fails to boot guests with more than one vCPU because they pass too small a buffer to VM_GET_CPUS, causing the ioctl handler to return ERANGE. Handle this the same way as cpuset system calls: make sure that the result can fit in the truncated space, and relax the check on the cpuset buffer. As a side effect, fix an insufficient bounds check on "size". The signed/unsigned comparison with sizeof(cpuset_t) fails to exclude negative values, so we can end up allocating impossibly large amounts of memory. Reviewed by: jhb MFC after: 1 week Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D41496
* sys: Remove $FreeBSD$: one-line bare tagWarner Losh2023-08-232-2/+0
| | | | | | | Remove /^\s*\$FreeBSD\$$\n/ Similar commit in current: (cherry picked from commit 78d146160dc5)
* sys: Remove $FreeBSD$: one-line sh patternWarner Losh2023-08-2318-18/+0
| | | | | | | Remove /^\s*#[#!]?\s*\$FreeBSD\$.*$\n/ Similar commit in current: (cherry picked from commit 031beb4e239b)
* sys: Remove $FreeBSD$: one-line .c patternWarner Losh2023-08-2382-164/+0
| | | | | | | Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/ Similar commit in current: (cherry picked from commit 685dc743dc3b)
generated by cgit v1.3 (git 2.53.0) at 2026-07-31 21:29:42 +0000