jhibbits [Sun, 4 Feb 2018 15:37:58 +0000 (15:37 +0000)]
Minimal changes for MPR to build on architectures with physical addresses larger than virtual
Summary:
Some architectures use large (36-bit) physical addresses, with smaller
virtual addresses. Casting between vm_paddr_t (or bus_addr_t) and void * is
considered illegal, so cast through uintptr_t. No functional change on existing
platforms.
asomers [Sun, 4 Feb 2018 14:49:55 +0000 (14:49 +0000)]
geom: don't write stack garbage in disk labels
Most consumers of g_metadata_store were passing in partially unallocated
memory, resulting in stack garbage being written to disk labels. Fix them by
zeroing the memory first.
gvirstor repeated the same mistake, but in the kernel.
Also, glabel's label contained a fixed-size string that wasn't
initialized to zero.
nwhitehorn [Sat, 3 Feb 2018 23:49:21 +0000 (23:49 +0000)]
Fix regression introduced in r328806, preventing boot at least on all
PowerPC Apple hardware, and likely all Open Firmware systems.
The loader would allocate memory for its heap at whatever address Open
Firmware gave it, which would in general be the lowest unallocated address,
usually starting a page or two above 0. As the kernel is linked at 1 MB,
and loader insists on running the kernel at its link address, any heap
larger than 1 MB would overlap the kernel, causing loader memory allocations
to corrupt the kernel and vice versa.
Although r328806 made this problem much worse by increasing the heap size
to 8 MB, causing 88% of the loader heap to overlap with the kernel, the
problem has always existed. The old heap size was 1 MB and, unless that
started exactly at zero, which would cause other problems, some number of
pages of the loader heap still overlapped with the kernel.
This patch solves the issue in two ways and cleans up some related code:
- Moves the loader heap inside of the loader. This guarantees that the
heap will be contiguous with the loader and simplifies the heap
allocation code at no cost, since the heap lives in BSS.
- Moves the loader, previously at 28 MB and dangerously close to the kernel
it loads, a bit higher to 44 MB. This has the effect of breaking loader
on non-embedded PPC machines with < 48 MB of RAM, but we did not support
those anyway.
The fundamental problem is that the way loader loads ELF files is
incredibly fragile, but that can't be fixed without fundamental
architectural changes.
marius [Sat, 3 Feb 2018 23:14:11 +0000 (23:14 +0000)]
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().
delphij [Sat, 3 Feb 2018 09:15:13 +0000 (09:15 +0000)]
After r328426, g_label depends on UFS (option FFS) code to read UFS
superblock, and the kernel will fail to link when UFS is not built
in. This commit makes it depend on a small portion of FFS bits and
thereby fixes build for this situation.
This is intended as an interim bandaid, and the actual superblock
reading code should probably be made independent of UFS, so we do
not need to depend on it (see kib@'s comment in the review for
details), and we will revisit this once the superblock check hashes
are all in place.
emaste [Sat, 3 Feb 2018 01:23:48 +0000 (01:23 +0000)]
Make cross-endian loader changes apply only to powerpc
The cross-endian loader change in r328536 (review D12422) broke symbol
loading on (at least) amd64 kernels. Temporarily paper over the issue
by restricting the cross-endian support to only powerpc, until a proper
fix arrives.
mckusick [Fri, 2 Feb 2018 23:26:52 +0000 (23:26 +0000)]
Check and report error returns from sbput(3) calls.
Convert to using cgput(3) for writing cylinder groups.
Check and report error returns from cgput(3).
dim [Fri, 2 Feb 2018 22:28:12 +0000 (22:28 +0000)]
Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to
6.0.0 (branches/release_60 r324090).
This introduces retpoline support, with the -mretpoline flag. The
upstream initial commit message (r323155 by Chandler Carruth) contains
quite a bit of explanation. Quoting:
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 typic al 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.
adrian [Fri, 2 Feb 2018 22:05:36 +0000 (22:05 +0000)]
[arswitch] begin tidying up the learning and ATU management, introduce ATU APIs.
* Refactor the initial learning configuration (port learning, address expiry,
handling address moving between ports, etc, etc) into a separate HAL routine
* and ensure that it's consistent between switch chips - the AR8216,8316,724x,9331
SoCs all share the same switch code.
* .. the AR8327 needs doing - the defaults seem OK for now
* .. the AR9340 is different but it's also programmed now.
* Add support for flushing a single port worth of ATU entries
* Add support for fetching the ATU table from AR8216 and derived chips
Tested:
* AR9344, Carambola 2
TODO:
* Further testing on other chips
* Add AR9340 support
* Add AR8327 support
imp [Fri, 2 Feb 2018 15:40:49 +0000 (15:40 +0000)]
Invent new LDR_INTERP for the loader interpreter to use. Use this in
preference to LIBFICL{,32}. LIBFICL{,32} are now always defined, but
LDR_INTERP{,32} is defined empty when building w/o forth (aka the
simple interpreter) and defined to LIBFICL{,32} when we are building
forth.
imp [Fri, 2 Feb 2018 15:01:49 +0000 (15:01 +0000)]
Remove pcibios forth support.
I had thought that this would be useful. However it was committed too
late, and wound up being unused. It's in the way of future work now,
so retire it rather than bring it forward.
imp [Fri, 2 Feb 2018 15:01:44 +0000 (15:01 +0000)]
These 4th words were an attempt to allow integration into the boot
loader scripts. However, that path won't be taken after all it
seems. Remove this code before it decays into uselessness. Also remove
build dependencies on forth no longer needed.
imp [Fri, 2 Feb 2018 15:01:33 +0000 (15:01 +0000)]
Retire pnp.4th and the code needed only for 4th words used here.
This has never been installed. It was added to the tree disconnected
to the build in FreeBSD 5 (17 years ago) and has never been used as
far as I can tell. The desired improvements never really happened
(despite a couple minor cleanups along the way). It's relevance is
long past, so better to retire it.
kib [Fri, 2 Feb 2018 11:56:30 +0000 (11:56 +0000)]
On pageout, in vnode generic pager, for partially dirty page, only
clear dirty bits for completely invalid blocks.
Otherwise we might not write out the last chunk that is shorter than
512 bytes, if the file end is not aligned on disk block boundary.
This become important after the r324794.
PR: 225586
Reported by: tris_vern@hotmail.com
Tested by: pho
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Merge r1.120 from NetBSD:
Fix a pretty simple, yet pretty tragic typo: we should return IPPROTO_DONE,
not IPPROTO_NONE. With IPPROTO_NONE we will keep parsing the header chain
on an mbuf that was already freed.
Reported by: Maxime Villard <max at m00nbsd dot net>
MFC after: 3 days
imp [Fri, 2 Feb 2018 06:32:26 +0000 (06:32 +0000)]
Centralize several variables.
MK_CTF, MK_SSP, MK_PROFILE, NO_PIC, and INTERNALLIB are always the
same, so set them in defs.mk. MAN= is common, so set it here too.
This removes a lot of boring repetition from the Makefiles that added
almost no value.
adrian [Fri, 2 Feb 2018 02:05:14 +0000 (02:05 +0000)]
[etherswitch] add the first pass of a simple API to flush and fetch the L2 address table from the ethernet switch.
This stuff may be a bit fluid during this -HEAD cycle as various other
switch features are added, but the current stuff is enough to drive
initial development and features on the atheros range of integrated
and external switches.
* add a method to flush the whole address table;
* add a method to flush all addresses on a given port;
* add a method to download the address table;
* .. and then a method to fetch entries from the address table.
The table fetch/read methods pass through to the drivers for now since
the drivers may implement different ways of fetching/caching the address
table data. The atheros devices for example fetch the table by
iterating over the table through a set of registers and so you need
to keep that locked whilst you iterate otherwise you may have the table
flushed half way by a port status change.
This is a no-op until the userland and arswitch code shows up.
adrian [Thu, 1 Feb 2018 21:58:52 +0000 (21:58 +0000)]
[atheros] Fix-up the base address stuff after I did a drive-by with the calibration data location.
The old way required the data to be present really early and copied it from
memory mapped NOR flash; this only worked during kernel boot but not for
ath/ath_hal modules.
hselasky [Thu, 1 Feb 2018 19:57:21 +0000 (19:57 +0000)]
Fix some recent regressions after r328436 in the LinuxKPI:
1) The OPW() function macro should have the same return type like the
function it executes.
2) The DEVFS I/O-limit should be enforced for all character device reads
and writes.
3) The character device file handle should be passable, same as for
DEVFS based file handles.
kevans [Thu, 1 Feb 2018 14:31:12 +0000 (14:31 +0000)]
D14130: stand/fdt: Rip out FDT VA tracking
Whether we should be overwriting the loaded FDT module with the 'fixed up'
version or not was questionable when this was added, and now that overlays
are possible this is downright wrong.
Overlays can increase the size of the blob, so writing it back to the
original VA will generally write past the end of the block and start
clobbering other things in memory.
Rip it out- it was questionable to begin with, it's doing bad things now,
and it serves no purpose since the modified blob will be copied into place
rather than relying on this to reflect the changes.
andrew [Thu, 1 Feb 2018 14:26:26 +0000 (14:26 +0000)]
Only promote userspace mappings to superpages. This was dropped in r328510,
however due to the break-before-make requirement on arm64 is is currently
unsafe to promote kernel pages.
When INVARIANTS is not set the 'last' variable is not used, which can generate
compiler warnings.
If this invariant is ever violated it'd result in a KASSERT failure in
refcount_release(), so this one is not strictly required.
nwhitehorn [Thu, 1 Feb 2018 05:31:24 +0000 (05:31 +0000)]
Change the default MSR values used when starting userland and kernel
threads from compile-time defines to global variables. This removes a
significant amount of duplicated runtime patches to the compile-time
defines, centralizing the conditional logic in the early startup code.
mckusick [Wed, 31 Jan 2018 22:49:50 +0000 (22:49 +0000)]
One of the vnode fields listed by vn_printf is the union of pointers
whose type depends on the type of vnode. Correct vn_printf so that
it correctly identifies the name of the pointer that it is printing.
Submitted by: Andreas Longwitz <longwitz at incore.de>
MFC after: 1 week
imp [Wed, 31 Jan 2018 22:46:05 +0000 (22:46 +0000)]
Break out the interpreters (simple and forth) w/o ifdefs. This is
akin to what Pedro Souza and Wojciech Koszek did in the lua GSoC with
interp.h, interp_simple.c and changes to interp.c and interp_forth.c,
but completely redone from scratch.
This effectively restores the spirit of r326712 (my first attempt to
bring in Pedro's and Wojciech's work) updated for new requirements
that had silently broke their original work. This change also differs
by using fixed function names instead of function pointers to simply
things. Only one interpreter at a time may be compiled in.
Also of note: we take a mutable string, pass it in via a const char *
pointer into intrp_forth's interp_run(). We then cast away the const
to pass into ficlExec since ficl would require extensive changes to
properly const-poison. See Sections 6.5.2.5 and 6.7.3 of C11 standard
noting it's only UB if you modify a const object through a non-const
pointer, but not char [] -> const char * -> char * as here.
wulf [Wed, 31 Jan 2018 22:17:52 +0000 (22:17 +0000)]
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.
marius [Wed, 31 Jan 2018 21:56:23 +0000 (21:56 +0000)]
Account for the fact that jemalloc 5.0.0 dropped STATIC_PAGE_SHIFT
in favor for using LG_PAGE directly and, thus, for the fact that
host and target don't necessarily use pages of the same sizes.
wulf [Wed, 31 Jan 2018 21:46:37 +0000 (21:46 +0000)]
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
wulf [Wed, 31 Jan 2018 21:14:59 +0000 (21:14 +0000)]
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.
jhb [Wed, 31 Jan 2018 18:03:40 +0000 (18:03 +0000)]
Update limits on makecontext() arguments in the setcontext_link test.
sparc64 and riscv do not support 10 arguments, but MIPS now does.
While here, combine clauses for architectures that support the same
number of arguments to reduce duplication.
jhb [Wed, 31 Jan 2018 18:02:02 +0000 (18:02 +0000)]
Add a new set of simple tests for makecontext().
In contrast to the existing NetBSD setcontext_link test, these tests
verify that passing from 1 to 6 arguments through to the callback function
work correctly which can be useful for testing ABIs which split arguments
between registers and the stack.
jhb [Wed, 31 Jan 2018 18:00:23 +0000 (18:00 +0000)]
Remove limitation of 6 arguments for makecontext() on mips.
This implementation spills additional arguments on the stack so works
fine with more than 6 arguments. I believe the check was just copied
over from sparc64 (which doesn't support spilling onto the stack)
jhb [Wed, 31 Jan 2018 17:57:59 +0000 (17:57 +0000)]
Remove bogus checks against NCARGS.
NCARGS isn't a limit on the number of arguments to pass to a function,
but the number of bytes that can be consumed by arguments to exec. As
such, it is not suitable for a limit on the count of arguments passed
to makecontext().
jhb [Wed, 31 Jan 2018 17:36:39 +0000 (17:36 +0000)]
Consistently use 16-byte alignment for MIPS N32 and N64.
- Add a new <machine/abi.h> header to hold constants shared between C
and assembly such as CALLFRAME_SZ.
- Add a new STACK_ALIGN constant to <machine/abi.h> and use it to
replace hardcoded constants in the kernel and makecontext(). As a
result of this, ensure the stack pointer on N32 and N64 is 16-byte
aligned for N32 and N64 after exec(), after pthread_create(), and
when sending signals rather than 8-byte aligned.
kib [Wed, 31 Jan 2018 14:36:27 +0000 (14:36 +0000)]
IBRS support, AKA Spectre hardware mitigation.
It is coded according to the Intel document 336996-001, reading of the
patches posted on lkml, and some additional consultations with Intel.
For existing processors, you need a microcode update which adds IBRS
CPU features, and to manually enable it by setting the tunable/sysctl
hw.ibrs_disable to 0. Current status can be checked in sysctl
hw.ibrs_active. The mitigation might be inactive if the CPU feature
is not patched in, or if CPU reports that IBRS use is not required, by
IA32_ARCH_CAP_IBRS_ALL bit.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D14029
avg [Wed, 31 Jan 2018 11:14:26 +0000 (11:14 +0000)]
vmm/svm: post LAPIC interrupts using event injection, not virtual interrupts
The virtual interrupt method uses V_IRQ, V_INTR_PRIO, and V_INTR_VECTOR
fields of VMCB to inject a virtual interrupt into a guest VM. This
method has many advantages over the direct event injection as it
offloads all decisions of whether and when the interrupt can be
delivered to the guest. But with a purely software emulated vAPIC the
advantage is also a problem. The problem is that the hypervisor does
not have any precise control over when the interrupt is actually
delivered to the guest (or a notification about that). Because of that
the hypervisor cannot update the interrupt vector in IRR and ISR in the
same way as real hardware would. The hypervisor becomes aware that the
interrupt is being serviced only upon the first VMEXIT after the
interrupt is delivered. This creates a window between the actual
interrupt delivery and the update of IRR and ISR. That means that IRR
and ISR might not be correctly set up to the point of the
end-of-interrupt signal.
The described deviation has been observed to cause an interrupt loss in
the following scenario. vCPU0 posts an inter-processor interrupt to
vCPU1. The interrupt is injected as a virtual interrupt by the
hypervisor. The interrupt is delivered to a guest and an interrupt
handler is invoked. The handler performs a requested action and
acknowledges the request by modifying a global variable. So far, there
is no VMEXIT and the hypervisor is unaware of the events. Then, vCPU0
notices the acknowledgment and sends another IPI with the same vector.
The IPI gets collapsed into the previous IPI in the IRR of vCPU1. Only
after that a VMEXIT of vCPU1 occurs. At that time the vector is cleared
in the IRR and is set in the ISR. vCPU1 has vAPIC state as if the
second IPI has never been sent.
The scenario is impossible on the real hardware because IRR and ISR are
updated just before the interrupt handler gets started.
I saw several possibilities of fixing the problem. One is to intercept
the virtual interrupt delivery to update IRR and ISR at the right
moment. The other is to deliver the LAPIC interrupts using the event
injection, same as legacy interrupts. I opted to use the latter
approach for several reasons. It's equivalent to what VMM/Intel does
(in !VMX case). It appears to be what VirtualBox and KVM do. The code
is already there (to support legacy interrupts).
Another possibility was to use a special intermediate state for a vector
after it is injected using a virtual interrupt and before it is known
whether it was accepted or is still pending.
That approach was implemented in https://reviews.freebsd.org/D13828
That method is more complex and does not have any clear advantage.
Please see sections 15.20 and 15.21.4 of "AMD64 Architecture
Programmer's Manual Volume 2: System Programming" (publication 24593,
revision 3.29) for comparison between event injection and virtual
interrupt injection.
projects / FreeBSD / FreeBSD.git / log