WireGuard implementation for the OpenBSD kernel https://git.zx2c4.com/wireguard-openbsd/atom/sys/arch/amd64/include/asm.h?h=jd%2Fqueueboosts 2019-04-02T03:35:08Z 2019-04-02T03:35:08Z mortimer mortimer@openbsd.org 2019-04-02T03:35:08Z urn:sha1:3fc877c6446eca8ae4a0f870894fff599cfeb121 following return. This change adds a constraint that the name passed to the RETGUARD_* macros must correspond to the name in the corresponding ENTRY which starts the function (or a function which appears beforehand in the same file). Since we use the distance from the ENTRY definition to calculate how much padding to insert, the ENTRY symbol must be in scope at assembly time. This is almost always the case already, since it is the natural way to name the retguard symbols so they remain unique. ok deraadt@ 2018-07-24T02:42:25Z guenther guenther@openbsd.org 2018-07-24T02:42:25Z urn:sha1:a1fa35384a2451a9a5f75e63d1e99a2902f0cfbd when vmlaunch or vmresume fails. Follow the lead of clang and the intel recommendation and do an lfence after the pause in the speculation-stop path for retpoline, RSB refill, and meltover ASM bits. ok kettenis@ deraadt@ 2018-07-23T17:54:04Z guenther guenther@openbsd.org 2018-07-23T17:54:04Z urn:sha1:a4858df8c5455654ebfa3e96349cf3f1eab81b02 and its associated appendix at https://support.google.com/faqs/answer/7625886 This should address at least some cases of "SpectreRSB" and earlier Spectre variants; more commits to follow. The refilling is done in the enter-kernel-from-userspace and return-to-userspace-from-kernel paths, making sure to do it before unblocking interrupts so that a successive interrupt can't get the CPU to C code without doing this refill. Per the link above, it also does it immediately after mwait, apparently in case the low-power CPU states of idle-via-mwait flush the RSB. ok mlarkin@ deraadt@ 2018-07-12T14:11:11Z guenther guenther@openbsd.org 2018-07-12T14:11:11Z urn:sha1:1fc8fad1ef00427ff55d700df3f3dfdb82455f63 traps so that the "mov %rax,%cr3" is followed by an infinite loop which is avoided because the mapping of the code being executed is changed. This means the sysretq/iretq isn't even present in that flow of instructions in the kernel mapping, so userspace code can't be speculatively reached on the kernel mapping and totally eliminates the conditional jump over the the %cr3 change that supported CPUs without the Meltdown vulnerability. The return paths were probably vulnerable to Spectre v1 (and v1.1/1.2) style attacks, speculatively executing user code post-system-call with the kernel mappings, thus creating cache/TLB/etc side-effects. Would like to apply this technique to the interrupt stubs too, but I'm hitting a bug in clang's assembler which misaligns the code and symbols. While here, when on a CPU not vulnerable to Meltdown, codepatch out the unnecessary bits in cpu_switchto(). Inspiration from sf@, refined over dinner with theo ok mlarkin@ deraadt@ 2018-07-10T16:01:26Z deraadt deraadt@openbsd.org 2018-07-10T16:01:26Z urn:sha1:a5910b4fbcaa3dd48faff38aeadcb22c953af71e ENTRY is a trapsled. Fix a few functions which fall-through into an ENTRY macro. amd64 binaries now are free of double+-nop sequences (except for one assember nit in aes-586.pl). Previous changes by guenther got us here. ok mortimer kettenis 2018-07-01T16:02:12Z guenther guenther@openbsd.org 2018-07-01T16:02:12Z urn:sha1:ec74cda27eab626d8fa3b1a587f5c1c2e9724873 ALIGN_TEXT. For the places where IDTVEC and KIDTVEC are used in ways that would fail if a trap was inserted, provide IDTVEC_NOALIGN for use directly after other IDTVEC uses, and KIDTVEC_FALLTHROUGH for places where the code intentionally falls through to a KIDTVEC. "objdump -d" shows that this just converts nop-sleds to trap-sleds immediately after an unconditional jmp, or a retq, iretq, or sysretq. ok mortimer@ kettenis@ deraadt@ 2018-07-01T12:13:50Z mortimer mortimer@openbsd.org 2018-07-01T12:13:50Z urn:sha1:b6cd93857594bceac7f2734519d1f90ef2f5d7b8 ok guenther@ 2018-07-01T04:47:32Z guenther guenther@openbsd.org 2018-07-01T04:47:32Z urn:sha1:b433e1a003445ba4a963e55728b2fcbe0962c8c2 use it where that was manually written before. No binary change. ok deraadt@ 2018-06-07T04:09:35Z guenther guenther@openbsd.org 2018-06-07T04:09:35Z urn:sha1:421775b1949acc6532e40380a6f6371ee4011aab ok mlarkin@ mortimer@ deraadt@ 2018-02-21T19:24:15Z guenther guenther@openbsd.org 2018-02-21T19:24:15Z urn:sha1:b767b017801a7911c8695888fb3667cbbba30f7b On Intel CPUs which speculate past user/supervisor page permission checks, use a separate page table for userspace with only the minimum of kernel code and data required for the transitions to/from the kernel (still marked as supervisor-only, of course): - the IDT (RO) - three pages of kernel text in the .kutext section for interrupt, trap, and syscall trampoline code (RX) - one page of kernel data in the .kudata section for TLB flush IPIs (RW) - the lapic page (RW, uncachable) - per CPU: one page for the TSS+GDT (RO) and one page for trampoline stacks (RW) When a syscall, trap, or interrupt takes a CPU from userspace to kernel the trampoline code switches page tables, switches stacks to the thread's real kernel stack, then copies over the necessary bits from the trampoline stack. On return to userspace the opposite occurs: recreate the iretq frame on the trampoline stack, switch stack, switch page tables, and return to userspace. mlarkin@ implemented the pmap bits and did 90% of the debugging, diagnosing issues on MP in particular, and drove the final push to completion. Many rounds of testing by naddy@, sthen@, and others Thanks to Alex Wilson from Joyent for early discussions about trampolines and their data requirements. Per-CPU page layout mostly inspired by DragonFlyBSD. ok mlarkin@ deraadt@