WireGuard implementation for the OpenBSD kernel https://git.zx2c4.com/wireguard-openbsd/atom/sys/arch/amd64/include/codepatch.h?h=jd%2Fqueueboosts 2020-03-11T07:27:08Z 2020-03-11T07:27:08Z guenther guenther@openbsd.org 2020-03-11T07:27:08Z urn:sha1:67ca69ecacf46c8d970d09c75497d3681d2aa2b8 kernel by using lfence in place of stac/clac on pre-SMAP CPUs. To quote from https://software.intel.com/security-software-guidance/insights/deep-dive-load-value-injection "If the OS makes use of Supervisor Mode Access Prevention (SMAP) on processors with SMAP enabled, then LVI on kernel load from user pages will be mitigated. This is because the CLAC and STAC instructions have LFENCE semantics on processors affected by LVI, and this serves as a speculation fence around kernel loads from user pages." ok deraadt@ 2020-02-28T05:22:52Z deraadt deraadt@openbsd.org 2020-02-28T05:22:52Z urn:sha1:457e2542acd92bc59edd0a7e4e606ab3a2dbe36a 2020-02-28T04:59:04Z deraadt deraadt@openbsd.org 2020-02-28T04:59:04Z urn:sha1:7042a378ac88afa0d0da70039d624b2851074ff2 2019-08-07T18:53:28Z guenther guenther@openbsd.org 2019-08-07T18:53:28Z urn:sha1:5c3fa5a3cf0f4823ae1dce174ce77d5435e353bc or mis-take swapgs in interrupt path and in trap/fault/exception path. The latter is improved to have no conditionals around this when Meltdown mitigation is in effect. Codepatch out the fences based on the description of CPU bugs in the (well written) Linux commit message. feedback from kettenis@ ok deraadt@ 2019-08-07T18:53:12Z guenther guenther@openbsd.org 2019-08-07T18:53:12Z urn:sha1:b8d87cb1272c7724c19189376543ea6aa67c01e2 tweaked based on feedback from kettenis@ ok deraadt@ 2019-05-17T19:07:15Z guenther guenther@openbsd.org 2019-05-17T19:07:15Z urn:sha1:a0dcb1783e6fe75c0d3cc06802415d3e715ac53b If the CPU has the new VERW behavior than that is used, otherwise use the proper sequence from Intel's "Deep Dive" doc is used in the return-to-userspace and enter-VMM-guest paths. The enter-C3-idle path is not mitigated because it's only a problem when SMT/HT is enabled: mitigating everything when that's enabled would be a _huge_ set of changes that we see no point in doing. Update vmm(4) to pass through the MSR bits so that guests can apply the optimal mitigation. VMM help and specific feedback from mlarkin@ vendor-portability help from jsg@ and kettenis@ ok kettenis@ mlarkin@ deraadt@ jsg@ 2018-10-04T05:00:40Z guenther guenther@openbsd.org 2018-10-04T05:00:40Z urn:sha1:f95e373fb5dc99ea1b42391f80bd0d1296af1362 This uses one PCID for kernel threads, one for the U+K tables of normal processes, one for the matching U-K tables (when meltdown in effect), and one for temporary mappings when poking other processes. Some further tweaks are envisioned but this is good enough to provide more separation and has (finally) been stable under ports testing. lots of ports testing and valid complaints from naddy@ and sthen@ feedback from mlarkin@ and sf@ 2018-07-13T08:30:34Z sf sf@openbsd.org 2018-07-13T08:30:34Z urn:sha1:5f6ecb1939a610ea2cc43585708e659fc0834e52 This way, it is not available for use in ROP attacks. This diff puts the codepatching code into a separate section and unmaps that section after boot. In the future, the memory could potentially be reused but that would require larger changes. ok pguenther@ 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-06-05T06:39:10Z guenther guenther@openbsd.org 2018-06-05T06:39:10Z urn:sha1:c9de630f2b8eca49826c5a19f6e33a38c26295b2 curproc's xstate ("extended state") is loaded in the CPU or not. - context switch, sendsig(), vmm, and doing CPU crypto in the kernel all check the flag and, if set, save the old thread's state to the PCB, clear the flag, and then load the _blank_ state - when returning to userspace, if the flag is clear then set it and restore the thread's state This simpler tracking also fixes the restoring of FPU state after nested signal handlers. With this, %cr0's TS flag is never set, the FPU #DNA trap can no longer happen, and IPIs are no longer necessary for flushing or syncing FPU state; on the other hand, restoring xstate while returning to userspace means we have to handle xrstor faulting if we could be loading an altered state. If that happens, reset the state, fake a #GP fault (SIGBUS), and recheck for ASTs. While here, regularize fxsave/fxrstor vs xsave/xrstor handling, by using codepatching to switch to xsave/xrstor when present in the CPU. In addition, code patch in use of xsaveopt in most places when the CPU supports that. Use the 64bit-wide variants of the instructions in all cases so that x87 instruction fault IPs are reported correctly. This change has three motivations: 1) with modern clang, SSE registers are used even in rcrt0.o, making lazy FPU switching a smaller benefit vs trap costs 2) the Intel SDM warns that lazy FPU switching may increase power costs 3) post-Spectre rumors suggest that the %cr0 TS flag might not block speculation, permitting leaking of information about FPU state (AES keys?) across protection boundaries. tested by many in snaps; prodding from deraadt@