#
362383 |
|
19-Jun-2020 |
kib |
MFC r362130: Control for Special Register Buffer Data Sampling mitigation.
|
#
361561 |
|
27-May-2020 |
kib |
MFC r361302: amd64: Add a knob to flush RSB on context switches if machine has SMEP.
|
#
358582 |
|
03-Mar-2020 |
kib |
MFC r358315: Fix IBRS for machines with IBRS_ALL capability.
|
#
349955 |
|
12-Jul-2019 |
jhb |
MFC 348210: Add a constant for the LS config MSR on AMD CPUs.
|
#
348362 |
|
29-May-2019 |
kib |
MFC r348075: Do not call hw_mds_recalculate() from initializecpu().
Approved by: re (gjb)
|
#
347568 |
|
14-May-2019 |
kib |
MFC r347566: Mitigations for Microarchitectural Data Sampling.
Reference: https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00233.html Security: CVE-2018-12126, CVE-2018-12127, CVE-2018-12130, CVE-2019-11091 Security: FreeBSD-SA-19:07.mds Reviewed by: jhb Tested by: emaste, lwhsu Approved by: so (gtetlow)
|
#
345414 |
|
22-Mar-2019 |
kib |
MFC r345190: Provide deterministic (and somewhat useful) value for RDPID result, and for %ecx after RDTSCP.
|
#
337235 |
|
03-Aug-2018 |
kib |
MFC r336763: Add workarounds for several Ryzen erratas, on amd64.
|
#
334152 |
|
24-May-2018 |
kib |
MFC r334004: Add Intel Spec Store Bypass Disable control.
This also includes the i386/include/pcpu.h part of the r334018.
Security: CVE-2018-3639 Approved by: re (gjb)
|
#
331722 |
|
29-Mar-2018 |
eadler |
Revert r330897:
This was intended to be a non-functional change. It wasn't. The commit message was thus wrong. In addition it broke arm, and merged crypto related code.
Revert with prejudice.
This revert skips files touched in r316370 since that commit was since MFCed. This revert also skips files that require $FreeBSD$ property changes.
Thank you to those who helped me get out of this mess including but not limited to gonzo, kevans, rgrimes.
Requested by: gjb (re)
|
#
330897 |
|
14-Mar-2018 |
eadler |
Partial merge of the SPDX changes
These changes are incomplete but are making it difficult to determine what other changes can/should be merged.
No objections from: pfg
|
#
329462 |
|
17-Feb-2018 |
kib |
MFC r328083,328096,328116,328119,328120,328128,328135,328153,328157, 328166,328177,328199,328202,328205,328468,328470,328624,328625,328627, 328628,329214,329297,329365:
Meltdown mitigation by PTI, PCID optimization of PTI, and kernel use of IBRS for some mitigations of Spectre.
Tested by: emaste, Arshan Khanifar <arshankhanifar@gmail.com> Discussed with: jkim Sponsored by: The FreeBSD Foundation
|
#
322569 |
|
16-Aug-2017 |
truckman |
MFC r321899
Lower the amd64 shared page, which contains the signal trampoline, from the top of user memory to one page lower on machines with the Ryzen (AMD Family 17h) CPU. This pushes ps_strings and the stack down by one page as well. On Ryzen there is some sort of interaction between code running at the top of user memory address space and interrupts that can cause FreeBSD to either hang or silently reset. This sounds similar to the problem found with DragonFly BSD that was fixed with this commit: https://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/b48dd28447fc8ef62fbc963accd301557fd9ac20 but our signal trampoline location was already lower than the address that DragonFly moved their signal trampoline to. It also does not appear to be related to SMT as described here: https://www.phoronix.com/forums/forum/hardware/processors-memory/955368-some-ryzen-linux-users-are-facing-issues-with-heavy-compilation-loads?p=955498#post955498
"Hi, Matt Dillon here. Yes, I did find what I believe to be a hardware issue with Ryzen related to concurrent operations. In a nutshell, for any given hyperthread pair, if one hyperthread is in a cpu-bound loop of any kind (can be in user mode), and the other hyperthread is returning from an interrupt via IRETQ, the hyperthread issuing the IRETQ can stall indefinitely until the other hyperthread with the cpu-bound loop pauses (aka HLT until next interrupt). After this situation occurs, the system appears to destabilize. The situation does not occur if the cpu-bound loop is on a different core than the core doing the IRETQ. The %rip the IRETQ returns to (e.g. userland %rip address) matters a *LOT*. The problem occurs more often with high %rip addresses such as near the top of the user stack, which is where DragonFly's signal trampoline traditionally resides. So a user program taking a signal on one thread while another thread is cpu-bound can cause this behavior. Changing the location of the signal trampoline makes it more difficult to reproduce the problem. I have not been because the able to completely mitigate it. When a cpu-thread stalls in this manner it appears to stall INSIDE the microcode for IRETQ. It doesn't make it to the return pc, and the cpu thread cannot take any IPIs or other hardware interrupts while in this state." since the system instability has been observed on FreeBSD with SMT disabled. Interrupts to appear to play a factor since running a signal-intensive process on the first CPU core, which handles most of the interrupts on my machine, is far more likely to trigger the problem than running such a process on any other core.
Also lower sv_maxuser to prevent a malicious user from using mmap() to load and execute code in the top page of user memory that was made available when the shared page was moved down.
Make the same changes to the 64-bit Linux emulator.
PR: 219399 Reported by: nbe@renzel.net Reviewed by: kib Reviewed by: dchagin (previous version) Tested by: nbe@renzel.net (earlier version) Differential Revision: https://reviews.freebsd.org/D11780
|
#
307997 |
|
27-Oct-2016 |
avg |
MFC r305539: work around AMD erratum 793 for family 16h, models 00h-0Fh
|
#
304130 |
|
15-Aug-2016 |
avg |
MFC r302835: fix-up for configuration of AMD Family 10h processors borrowed from Linux
|