WireGuard implementation for the OpenBSD kernel https://git.zx2c4.com/wireguard-openbsd/atom/sys/arch/amd64/include/proc.h?h=jd%2Fqueueboosts 2018-06-05T06:39:10Z 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@ 2017-04-13T03:52:25Z guenther guenther@openbsd.org 2017-04-13T03:52:25Z urn:sha1:f5d56f6d1abf3988ecad6e5bcc0d9e60de25e475 in struct mdproc. With that, all archs have those and the __HAVE_MD_TCB macro can be unifdef'ed as always defined. ok kettenis@ visa@ jsing@ 2014-03-29T18:09:28Z guenther guenther@openbsd.org 2014-03-29T18:09:28Z urn:sha1:2df76cc2a0aee2cb2166e3799b7bb5c3f883f83d ok dlg@ mpi@ deraadt@ 2011-10-15T23:35:29Z guenther guenther@openbsd.org 2011-10-15T23:35:29Z urn:sha1:6bb855475d0cdbaa6e89d93537105bdf30f02caf for pointing to the thread-control-block. Support for mapping this to the correct hardware register can be added as it's finished; start with support for amd64, sparc, and sparc64. Includes syscalls for getting and setting it (for a portable __errno implementation) as well as creating a new thread with an initial value for it. discussed with miod@, kettenis@, deraadt@; committing to get the syscalls in with the impending libc bump and do further refinements in tree 2011-03-23T16:54:33Z pirofti pirofti@openbsd.org 2011-03-23T16:54:33Z urn:sha1:2fa72412907ae78c4787a4a8f888c5f0486e225c Discussed and okay drahn@. Okay deraadt@. 2011-03-18T03:10:47Z guenther guenther@openbsd.org 2011-03-18T03:10:47Z urn:sha1:0118571e2532f99a6e935bf0729c4ccbaa9d6190 of them, as well as some other unused proc md_flags bits: MDP_COMPAT and MDP_SYSCALL. ok mikeb@ 2010-11-13T04:16:42Z guenther guenther@openbsd.org 2010-11-13T04:16:42Z urn:sha1:fd94711f2c2fd92458999b68835ea82cc4ba80bc next to the cpu's GDT, also making the double-fault stack per-CPU, leaving it at the top of the page of the CPU's idle process. Inline pmap_activate() and pmap_deactivate() into the asm cpu_switchto routine, adding a check for the new pmap already being marked as active on the CPU. Garbage collect the hasn't-been-used-in-years GDT update IPI. Tested by many; ok mikeb@, kettenis@ 2005-12-13T00:18:18Z jsg jsg@openbsd.org 2005-12-13T00:18:18Z urn:sha1:c5217b0a4d8ddcc3e5ff2eee068850fd31edb768 rescinded 22 July 1999. Checked by ian@, deraadt@ and millert@, arm portion checked by drahn@ 2004-05-13T20:20:24Z sturm sturm@openbsd.org 2004-05-13T20:20:24Z urn:sha1:4e1a77ce46c350280ff45c43cb3d699a111883b9 instead use syscall() as everywhere else ok mickey, tested and ok tedu@ 2004-01-28T01:39:38Z mickey mickey@openbsd.org 2004-01-28T01:39:38Z urn:sha1:f5df1827e930693b77256fbf32ab5050c01d960c hacked by art@ from netbsd sources and then later debugged by me into the shape where it can host itself. no bootloader yet as needs redoing from the recent advanced i386 sources (anyone? ;)