dim [Mon, 19 Mar 2018 18:36:43 +0000 (18:36 +0000)]
Merge retpoline support from the upstream llvm, clang and lld 5.0
branches. Upstream merge revisions:
r324007: merging r323155 for llvm
r324009: merging r323915 for llvm
r324012: merging r323155 for clang
r324025: merging r323155 for lld, with modifications to
handle int3 fill
r324026: merging r323288 for lld
r325088: merging r324449 for llvm
r325089: merging r324645 for llvm
r325090: merging r325049 for llvm
r325091: merging r325085 for llvm
Original commit messages:
r323155 (by Chandler Carruth):
Introduce the "retpoline" x86 mitigation technique for variant #2 of
the speculative execution vulnerabilities disclosed today,
specifically identified by CVE-2017-5715, "Branch Target Injection",
and is one of the two halves to Spectre.
Summary:
First, we need to explain the core of the vulnerability. Note that
this is a very incomplete description, please see the Project Zero
blog post for details:
https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html
The basis for branch target injection is to direct speculative
execution of the processor to some "gadget" of executable code by
poisoning the prediction of indirect branches with the address of
that gadget. The gadget in turn contains an operation that provides a
side channel for reading data. Most commonly, this will look like a
load of secret data followed by a branch on the loaded value and then
a load of some predictable cache line. The attacker then uses timing
of the processors cache to determine which direction the branch took
*in the speculative execution*, and in turn what one bit of the
loaded value was. Due to the nature of these timing side channels and
the branch predictor on Intel processors, this allows an attacker to
leak data only accessible to a privileged domain (like the kernel)
back into an unprivileged domain.
The goal is simple: avoid generating code which contains an indirect
branch that could have its prediction poisoned by an attacker. In
many cases, the compiler can simply use directed conditional branches
and a small search tree. LLVM already has support for lowering
switches in this way and the first step of this patch is to disable
jump-table lowering of switches and introduce a pass to rewrite
explicit indirectbr sequences into a switch over integers.
However, there is no fully general alternative to indirect calls. We
introduce a new construct we call a "retpoline" to implement indirect
calls in a non-speculatable way. It can be thought of loosely as a
trampoline for indirect calls which uses the RET instruction on x86.
Further, we arrange for a specific call->ret sequence which ensures
the processor predicts the return to go to a controlled, known
location. The retpoline then "smashes" the return address pushed onto
the stack by the call with the desired target of the original
indirect call. The result is a predicted return to the next
instruction after a call (which can be used to trap speculative
execution within an infinite loop) and an actual indirect branch to
an arbitrary address.
On 64-bit x86 ABIs, this is especially easily done in the compiler by
using a guaranteed scratch register to pass the target into this
device. For 32-bit ABIs there isn't a guaranteed scratch register
and so several different retpoline variants are introduced to use a
scratch register if one is available in the calling convention and to
otherwise use direct stack push/pop sequences to pass the target
address.
This "retpoline" mitigation is fully described in the following blog
post: https://support.google.com/faqs/answer/7625886
We also support a target feature that disables emission of the
retpoline thunk by the compiler to allow for custom thunks if users
want them. These are particularly useful in environments like
kernels that routinely do hot-patching on boot and want to hot-patch
their thunk to different code sequences. They can write this custom
thunk and use `-mretpoline-external-thunk` *in addition* to
`-mretpoline`. In this case, on x86-64 thu thunk names must be:
```
__llvm_external_retpoline_r11
```
or on 32-bit:
```
__llvm_external_retpoline_eax
__llvm_external_retpoline_ecx
__llvm_external_retpoline_edx
__llvm_external_retpoline_push
```
And the target of the retpoline is passed in the named register, or
in the case of the `push` suffix on the top of the stack via a
`pushl` instruction.
There is one other important source of indirect branches in x86 ELF
binaries: the PLT. These patches also include support for LLD to
generate PLT entries that perform a retpoline-style indirection.
The only other indirect branches remaining that we are aware of are
from precompiled runtimes (such as crt0.o and similar). The ones we
have found are not really attackable, and so we have not focused on
them here, but eventually these runtimes should also be replicated
for retpoline-ed configurations for completeness.
For kernels or other freestanding or fully static executables, the
compiler switch `-mretpoline` is sufficient to fully mitigate this
particular attack. For dynamic executables, you must compile *all*
libraries with `-mretpoline` and additionally link the dynamic
executable and all shared libraries with LLD and pass `-z
retpolineplt` (or use similar functionality from some other linker).
We strongly recommend also using `-z now` as non-lazy binding allows
the retpoline-mitigated PLT to be substantially smaller.
When manually apply similar transformations to `-mretpoline` to the
Linux kernel we observed very small performance hits to applications
running typical workloads, and relatively minor hits (approximately
2%) even for extremely syscall-heavy applications. This is largely
due to the small number of indirect branches that occur in
performance sensitive paths of the kernel.
When using these patches on statically linked applications,
especially C++ applications, you should expect to see a much more
dramatic performance hit. For microbenchmarks that are switch,
indirect-, or virtual-call heavy we have seen overheads ranging from
10% to 50%.
However, real-world workloads exhibit substantially lower performance
impact. Notably, techniques such as PGO and ThinLTO dramatically
reduce the impact of hot indirect calls (by speculatively promoting
them to direct calls) and allow optimized search trees to be used to
lower switches. If you need to deploy these techniques in C++
applications, we *strongly* recommend that you ensure all hot call
targets are statically linked (avoiding PLT indirection) and use both
PGO and ThinLTO. Well tuned servers using all of these techniques saw
5% - 10% overhead from the use of retpoline.
We will add detailed documentation covering these components in
subsequent patches, but wanted to make the core functionality
available as soon as possible. Happy for more code review, but we'd
really like to get these patches landed and backported ASAP for
obvious reasons. We're planning to backport this to both 6.0 and 5.0
release streams and get a 5.0 release with just this cherry picked
ASAP for distros and vendors.
This patch is the work of a number of people over the past month:
Eric, Reid, Rui, and myself. I'm mailing it out as a single commit
due to the time sensitive nature of landing this and the need to
backport it. Huge thanks to everyone who helped out here, and
everyone at Intel who helped out in discussions about how to craft
this. Also, credit goes to Paul Turner (at Google, but not an LLVM
contributor) for much of the underlying retpoline design.
[x86] Make the retpoline thunk insertion a machine function pass.
Summary:
This removes the need for a machine module pass using some deeply
questionable hacks. This should address PR36123 which is a case where
in full LTO the memory usage of a machine module pass actually ended
up being significant.
We should revert this on trunk as soon as we understand and fix the
memory usage issue, but we should include this in any backports of
retpolines themselves.
[x86/retpoline] Make the external thunk names exactly match the names
that happened to end up in GCC.
This is really unfortunate, as the names don't have much rhyme or
reason to them. Originally in the discussions it seemed fine to rely
on aliases to map different names to whatever external thunk code
developers wished to use but there are practical problems with that
in the kernel it turns out. And since we're discovering this
practical problems late and since GCC has already shipped a release
with one set of names, we are forced, yet again, to blindly match
what is there.
Somewhat rushing this patch out for the Linux kernel folks to test
and so we can get it patched into our releases.
This allows the register name to be printed without the leading '%'.
This can be used for emitting calls to the retpoline thunks from
inline asm.
r325049 (by Reid Kleckner):
[X86] Use EDI for retpoline when no scratch regs are left
Summary:
Instead of solving the hard problem of how to pass the callee to the
indirect jump thunk without a register, just use a CSR. At a call
boundary, there's nothing stopping us from using a CSR to hold the
callee as long as we save and restore it in the prologue.
Also, add tests for this mregparm=3 case. I wrote execution tests for
__llvm_retpoline_push, but they never got committed as lit tests,
either because I never rewrote them or because they got lost in merge
conflicts.
dab [Mon, 19 Mar 2018 17:37:51 +0000 (17:37 +0000)]
MFC r331015:
Modify rc.d/fsck to handle new status from fsck/fsck_ffs
r328013 introduced a new error code from fsck_ffs that indicates that
it could not completely fix the file system; this happens when it
prints the message PLEASE RERUN FSCK. However, this status can happen
when fsck is run in "preen" mode and the rc.d/fsck script does not
handle that error code. Modify rc.d/fsck so that if "fsck -p"
("preen") returns the new status code (16) it will run "fsck -y", as
it currently does for a status code of 8 (the "standard error exit").
marius [Mon, 19 Mar 2018 14:28:20 +0000 (14:28 +0000)]
MFC: r328834
o Let rtld(1) set up psABI user trap handlers prior to executing the
objects' init functions instead of doing the setup via a constructor
in libc as the init functions may already depend on these handlers
to be in place. This gets us rid of:
- the undefined order in which libc constructors as __guard_setup()
and jemalloc_constructor() are executed WRT __sparc_utrap_setup(),
- the requirement to link libc last so __sparc_utrap_setup() gets
called prior to constructors in other libraries (see r122883).
For static binaries, crt1.o still sets up the user trap handlers.
o Move misplaced prototypes for MD functions in to the MD prototype
section of rtld.h.
o Sprinkle nitems().
ae [Mon, 19 Mar 2018 09:52:16 +0000 (09:52 +0000)]
MFC r330792:
Do not try to reassemble IPv6 fragments in "reass" rule.
ip_reass() expects IPv4 packet and will just corrupt any IPv6 packets
that it gets. Until proper IPv6 fragments handling function will be
implemented, pass IPv6 packets to next rule.
eadler [Mon, 19 Mar 2018 07:34:24 +0000 (07:34 +0000)]
MFC r322674:
Add Thunderbolt Apple interfaces to the bge(4) supported list.
Document message reported by kernel upon removal in DIAGNOSTIC section.
Document shortcomings in BUGS section.
eadler [Mon, 19 Mar 2018 07:03:02 +0000 (07:03 +0000)]
MFC r315986:
Fix 3 entries in mode tables related to mono and 90-column text modes.
Newer VGAs don't support any mono modes, but bugs in the tables created
2 virtual mono modes (#45 90x43 and #112 80x43) that behaved more
strangely than crashing. 90-column modes are tweaked 80-column ones
and also fail to work on newer VGAs. #45 did crash (hang) on some
hardware.
eadler [Mon, 19 Mar 2018 06:54:16 +0000 (06:54 +0000)]
MFC r326437:
Correct history for Unix 2nd Edition through 6th Edition for the
system calls. Man pages are missing for v2 and v5, so any entries for
those versions were inferred by new implementations of these functions
in libc.
eadler [Mon, 19 Mar 2018 06:45:40 +0000 (06:45 +0000)]
MFC r316422:
Remove checks that background (bg) colors are not bright and buggy
attempts to keep them that way. The bg brightness bit is interpreted
as blinking in some modes, but it would barely be useful to disallow
setting it when it would give blinking in code which knew when that
is. The old code mostly knew this wrong, and added handling errors.
It is in fact impossible to know, since future mode switches may
change the meaning of the bit many times on the screen and in history.
Old versions of vidcontrol disallowed bg color numbers >= 8 in all
cases. This is very VGA/syscons-centric. Syscons uses the VGA defaults
of blinking fg instead of bright bg in text mode and bright bg in
graphics mode. On VGA, this is very easy to toggle at any time, and
vt blows away the VGA text mode default at boot time.
r146736 changed this to try to allow bg color numbers in graphics mode
only. This is even more VGA/syscons-centric, and there are many bugs
in this, and many nearby bugs in the parser. These are increased or
decreased by differences and bugs in vt and teken.
Perhaps the most obvious bug was that almost any vidcontrol command
which changes any color or the mode causes an error if the initial fg
color is bright. E.g., in syscons text mode, after "vidcontrol
lightwhite" to make the fg bright, another "vidcontrol lightwhite" is
rejected and buggy fixup code changes the fg to white. This is because
the bright fg color creates a bright bg color for the phantom reverse
video attribute, so was rejected. (The reverse video attribute is
phantom because teken ignores the user's setting of it and simply
reverses the fg attributes to create the bg attributes. Sometimes
some layer masks off the brightness/blinking bit, but not here.)
Perhaps the next most obvious one was that "vidcontrol lightgreen
lightblue" was misparsed as 2 settings of the fg instead of 1 setting
of the fg and 1 invalid setting of the bg. This is because the
parser supports an undocumented syntax with many parsing bugs (an
ambiguity gives this one).
I recently fix bugs in teken that broke setting of bright fg's and
bg's in the normal way. This gave more settings of then, so the old
bugs showed up more often.
eadler [Mon, 19 Mar 2018 03:49:54 +0000 (03:49 +0000)]
MFC r328640:
psm: Add a kludge to support 0x46 identity middle byte Synaptics touchpads
Most synaptics touchpads return 0x47 in middle byte in responce to identify
command as stated in p.4.4 of "Synaptics PS/2 TouchPad Interfacing Guide".
But some devices e.g. found on HP EliteBook 9470m return 0x46 here.
Allow them to be identified as Synaptics as well as 0x47.
ExtendedQueries return incorrect data on such a touchpads so we ignore
their result and set conservative defaults.
eadler [Mon, 19 Mar 2018 03:47:46 +0000 (03:47 +0000)]
MFC r328638:
psm(4): Reduce psm watchdog verbosity
Modern touchpads do not issue interrupts on inactivity so "lost interrupt"
message became annoying spam nowadays. This change quiets the message
if debug.psm.loglevel=5 (or less) is set in /boot/loader.conf
eadler [Mon, 19 Mar 2018 03:46:12 +0000 (03:46 +0000)]
MFC r328636:
psm(4): Add support for HP EliteBook 1040 ForcePads.
ForcePads do not have any physical buttons, instead they detect click
based on finger pressure. Forcepads erroneously report button click
if there are 2 or more fingers on the touchpad breaking multifinger
gestures. To workaround this start reporting a click only after
4 consecutive single touch packets has been received. Skip these packets
in case more contacts appear.
eadler [Mon, 19 Mar 2018 03:22:43 +0000 (03:22 +0000)]
MFC r320210:
join(1): Fix field ordering for -v output
Per POSIX, join(1) (in modes other than -o) is a concatenation of selected
character fields. The joined field is first, followed by fields in the
order they occurred in the input files.
Our join(1) utility previously handled this correctly for lines with a match
in the other file. But it failed to order output fields correctly for
unmatched lines, printed in -a and -v modes.
A simple test case is:
$ touch a
$ echo "2 1" > b
$ join -v2 -2 2 a b
1 2
eadler [Sun, 18 Mar 2018 22:24:29 +0000 (22:24 +0000)]
MFC r319274:
- Add a simple example to uname(1) manual page to show how the hardware
platform (returned by -m) can be different from the machine's processor
architecture (-p)
- Document that make(1) sets universal MACHINE and MACHINE_ARCH variables
based on these values
indent(1): avoid calling write(2) with a negative second parameter.
indent(1): Avoid out of bound access of array codebuf.
indent(1): Avoid potential use-after-free.
indent(1): Fix breakage caused by single comment following "else".
indent(1) simply wasn't taught that "else" may be followed by a comment
without any opening brace anywhere on the line, so it was very confused
in such cases.
indent(1): fix struct termination detection.
indent(1): fix struct termination detection.
indent(1): Removed whitespace shouldn't be considered in column calculations.
indent(1): Support "f" and "F" floating constant suffixes.
indent(1): Use NULL instead of zero for pointers.
indent(1): Attempt to preserve some consistent style.
indent(1): Yet more style issues.
indent(1): Consistently indent declarations.
indent(1): Bail out if there's no more space on the parser stack.
indent(1): Remove dead code relating to unix-style comments.
indent(1): Simplify pr_comment().
indent(1): Fix wrapping of some lines in comments.
indent(1): Untangle the connection between pr_comment.c and io.c.
indent(1): Don't newline on cpp lines like #endif unless -bacc is on.
indent(1): replace function call to bzero with memset.
indent(1): Rearrange option parsing code to squelch clang's static analyzer.
indent(1): Use a dash in the license headers.
indent(1): accept offsetof(3) as a keyword.
indent(1): add some comments to quiet down Coverity.
indent(1): remove dead assignments.
indent(1): have the memset invocation somewhat more canonical.
indent(1): Capsicumify
indent(1): minor off-by-one error.
indent(1): fix regression introduced in r303596.
indent(1): Avoid out of bound access of array in_buffer
indent(1): Don't ignore newlines after comments that follow braces.
indent(1): Don't unnecessarily add a blank before a comment ends.
indent(1): Do not define opchar unless it will be used.
indent(1): Optimize parser stack usage.
indent(1): Remove an extra newline added in a previous commit.
indent(1): Avoid out-of-bound accesses of arrays.
indent(1): Avoid out-of-bound accesses of array ps.p_stack.
indent(1): Avoid out of bounds access of array ps.paren_indents
indent(1): add a piece missed in r311138.
indent(1): Support binary integer literals.
indent(1): don't produce unnecessary blank lines.
indent(1): rename the profile file.
indent(1): better alignment of comments on code.
imp [Sun, 18 Mar 2018 19:05:06 +0000 (19:05 +0000)]
Direct commit to stable
Remove libstand32 here. pc98 is a 32-bit platform, so it shouldn't compile
the extra 32-bit copy of libsa. The copy built in libstand is already 32-bit.
Add a comment saying we need an empty Makefile.pc98 since otherwise it would
pull in Makefile.i386 and there is no EFI on pc98, and the machines are too
old to have ZFS or GELI be a viable option (and besides, those don't compile).
Note: We also need r331140 to be MFC'd for pc98 build to work in all cases.
kp [Sun, 18 Mar 2018 11:25:39 +0000 (11:25 +0000)]
MFC r329950:
pf: Cope with overly large net.pf.states_hashsize
If the user configures a states_hashsize or source_nodes_hashsize value we may
not have enough memory to allocate this. This used to lock up pf, because these
allocations used M_WAITOK.
Cope with this by attempting the allocation with M_NOWAIT and falling back to
the default sizes (with M_WAITOK) if these fail.
PR: 209475
Submitted by: Fehmi Noyan Isi <fnoyanisi AT yahoo.com>
eadler [Sun, 18 Mar 2018 02:59:14 +0000 (02:59 +0000)]
MFC r330843:
efirtc: Pass a dummy tmcap pointer to efi_get_time_locked
As noted in the comment, UEFI spec claims the capabilities pointer is
optional, but some implementations will choke and attempt to dereference it
without checking. This specific problem was found on a Lenovo Thinkpad X220
that would panic in efirtc_identify.
dim [Sat, 17 Mar 2018 19:04:36 +0000 (19:04 +0000)]
Revert r330471 (MFC of r311861), since it results in compile errors
like:
sys/net80211/ieee80211_tdma.c:179: error: 'IEEE80211_MODE_VHT_2GHZ' undeclared (first use in this function)
sys/net80211/ieee80211_tdma.c:180: error: 'IEEE80211_MODE_VHT_5GHZ' undeclared (first use in this function)
The IEEE80211_MODE_VHT_2GHZ and IEEE80211_MODE_VHT_5GHZ enum values are
defined in r310147, but that commit cannot be MFCd as-is, because it
likely breaks ABI.
dim [Sat, 17 Mar 2018 18:55:46 +0000 (18:55 +0000)]
Repair obvious mismerge in r330897, resulting in misleading gcc error
messages like "sys/net/if_fddisubr.c:1: error: expected '=', ',', ';',
'asm' or '__attribute__' before '-' token".
eadler [Sat, 17 Mar 2018 01:27:54 +0000 (01:27 +0000)]
MFC r326959:
arc lint: ignore /tests/ in chmod
shell scripts in scripts don't need
to be chmod +x to work. In fact most are not.
Of the tests I found from a simple search:
65 are chmod +x
84 are chmod -x
patch(1): replace strnlen() with a simpler strlen().
patch(1): add support for git generated diffs.
patch: rejname[] is also -r option buffer, and should be PATH_MAX.
patch: further cleanup to git-style diffs.
The Genesys chip is failing when issueing READ_CAP(16) command.
Force a quirk to disable it and use READ_CAP(10) instead.
Also, depending on used firmware, GL3224 can be recognized
either as 'storage device' or 'mass storage class' -
enable both variants in scsi_quirk_table.
marius [Thu, 15 Mar 2018 23:02:49 +0000 (23:02 +0000)]
MFC: r327929
Use the correct revision specifier (EXT_CSD revision rather than
system specification version) for deciding whether the EXT_CSD
register includes the EXT_CSD_GEN_CMD6_TIME field.
marius [Thu, 15 Mar 2018 23:01:00 +0000 (23:01 +0000)]
MFC: r327355, r327926
- Don't allow userland to switch partitions; it's next to impossible
to recover from that, especially when something goes wrong.
- When userland changes EXT_CSD, update the kernel copy before using
relevant EXT_CSD bits in mmcsd_switch_part().
marius [Thu, 15 Mar 2018 22:58:31 +0000 (22:58 +0000)]
MFC: r327339, r327924
- There is no need to keep the tuning error and re-tuning interrupts
enabled (though, no interrupt generation enabled for them) all the
time as soon as (re-)tuning is supported; only enable them and let
them generate interrupts when actually using (re-)tuning.
- Also disable all interrupts except SDHCI_INT_DATA_AVAIL ones while
executing tuning and not just their signaling.
- Set the tuning error and re-tuning interrupt enable bits based on
the SDHCI_TUNING_ENABLED rather than the SDHCI_TUNING_SUPPORTED flag,
i. e. only when (re-)tuning is actually used. Currently, this change
makes no net difference, though.
kevans [Thu, 15 Mar 2018 19:31:39 +0000 (19:31 +0000)]
MFC r322278,324177: EFIRT Improvements
r322278 (imp): Fail to open efirt device when no EFI on system.
libefivar expects opening /dev/efi to indicate if the we can make efi
runtime calls. With a null routine, it was always succeeding leading
efi_variables_supported() to return the wrong value. Only succeed if
we have an efi_runtime table. Also, while I'm hear, out of an
abundance of caution, add a likely redundant check to make sure
efi_systbl is not NULL before dereferencing it. I know it can't be
NULL if efi_cfgtbl is non-NULL, but the compiler doesn't.
r324177 (andrew):
To prepare for adding EFI runtime services support on arm64 move the
machine independent parts of the existing code to a new file that can be
shared between amd64 and arm64.
Care has been taken to ensure that the MFC of r324177 did not clobber
cherry-picked MFC's.
emaste [Thu, 15 Mar 2018 12:56:22 +0000 (12:56 +0000)]
MFC r329370, r330239: Rationalize license text on Linuxolator files
Many licenses on Linuxolator files contained small variations from the
standard FreeBSD license text. To avoid license proliferation switch to
the standard 2-clause FreeBSD license for those files where I have
permission from each of the listed copyright holders.
Approved by: dchagin, kan, marcel, rdivacky, sos
Sponsored by: The FreeBSD Foundation