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)
While here, centralize the macros in <x86/fpu.h>.
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D42135
(cherry picked from commit cc1cb9ea0c5607931fa9b7ecf786468d38fb8491)
We only want to produce syscall.mk for the main syscall table so default
to not producing it (send it to /dev/null) and add a syscalls.conf to
sys/kern to trigger the creation of sys/sys/syscall.mk. This eliminates
the need for entries in other syscalls.conf files and is a cleaner
pattern going forward.
Reviewed by: kevans, imp
Differential Revision: https://reviews.freebsd.org/D42663
(cherry picked from commit 54d487c4d01d68ef0ac03eae1fc574f7533d46f6)
With clang it expands to "inline"; clang in practice may inline
externally visible functions even without the hint. So just remove the
hints and let the compiler decide.
No functional change intended. pmap.o is identical before and after
this patch.
Reviewed by: alc
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D42446
(cherry picked from commit 2b084923824e0d5133fe5aff580b4e562fe7dd19)
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)
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: c08973d09c Workaround for Intel SKL002/SKL012S errata
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D42311
(cherry picked from commit 9e7f349ff10691c2e3fb03898dbc942794a47566)
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)
To match the sysctl MIBs and document entries in security(7).
Fixes: 2dec2b4a34 amd64: flush L1 data cache on syscall return with an error
Fixes: 17edf152e5 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)
At least KMSAN relies on zero-initialization of AP PCPU regions, see
commit 4b136ef259.
Prior to commit af1c6d3f30 these were allocated with allocpages() in
the amd64 pmap, which always returns zero-initialized memory.
Reviewed by: kib
Fixes: af1c6d3f30 ("amd64: do not leak pcpu pages")
MFC after: 3 days
Sponsored by: Klara, Inc.
Sponsored by: Juniper Networks, Inc.
Differential Revision: https://reviews.freebsd.org/D42241
(cherry picked from commit a37e484d049758c70f2d61be0d28a115b6f2f01e)
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)
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)
This patch reverts the changes made in D19670 and fixes the original
issue by allocating and prepopulating a leaf page table page for wired
userspace 2M pages.
The original issue is an edge case that creates an unmapped, wired
region in userspace. Subsequent faults on this region can trigger wired
superpage creation, which leads to a panic in pmap_demote_pde_locked()
as the pmap does not create a leaf page table page for the wired
superpage. D19670 fixed this by disallowing preemptive creation of
wired superpage mappings, but that fix is currently interfering with an
ongoing effort of speeding up vm_map_wire for large, contiguous entries
(e.g. bhyve wiring guest memory).
Reviewed by: alc, markj
Sponsored by: Google, Inc. (GSoC 2023)
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D41132
(cherry picked from commit aa3bcaad51076ceb346fa0c64ab69a35e5241b20)
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)
To help porting the Linux emulation layer to a new platforms start using
Linux names for conditional builds instead of architecture-specific ifdefs.
MFC after: 1 week
(cherry picked from commit 2a1cf1b6b55c8326bbe85d0fdf17b0f2fb9b34ce)
For amd64, i386, arm, and riscv, i.e. all architectures except arm64,
the custom implementation is provided since we maintain the bitmask of
active CPUs anyway.
Arm64 uses somewhat naive iteration over CPUs and match current vmspace'
pmap with the argument. It is not guaranteed that vmspace->pmap is the
same as the active pmap, but the inaccuracy should be toleratable.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D32360
Adding a writev syscall wrapper is needed due to Linux family of write
syscalls doesn't distinguish between in kernel blocking operations
and always returns EAGAIN while FreeBSD can return ENOBUFS.
MFC after: 1 month
Adding a writev syscall wrapper is needed due to Linux family of write
syscalls doesn't distinguish between in kernel blocking operations
and always returns EAGAIN while FreeBSD can return ENOBUFS.
MFC after: 1 month
Adding a write syscall wrapper is needed due to Linux family of write
syscalls doesn't distinguish between in kernel blocking operations
and always returns EAGAIN while FreeBSD can return ENOBUFS.
MFC after: 1 month
Adding a write syscall wrapper is needed due to Linux family of write
syscalls doesn't distinguish between in kernel blocking operations
and always returns EAGAIN while FreeBSD can return ENOBUFS.
MFC after: 1 month
