wireguard-openbsd/sys/arch/amd64/include, branch jd/queueboosts

pci_intr_establish_cpu() for establishing an interrupt no a specific cpu.

2020-06-17T06:14:52Z

the cpu is specified by a struct cpu_info *, which should generally come from an intrmap. this is adapted from a diff that patrick@ sent round a few years ago for a pci_intr_map_msix_cpuid, where you asked for an msi vector on a specific cpu, and then called pci_intr_establish with the handle you get. kettenis pointed out that it's hard on some archs to carry cpu on a pci interrupt handle, so i tweaked it to turn it into a pci_intr_establish_cpu instead. jmatthew@ and i (but mostly jmatthew@ to be honest) have been experimenting with this api on multiple archs and it is working out well. i'm putting this diff in now on amd64 so people can kick the tyres a bit. tested with hacked up vmx(4), ix(4), and mcx(4)

let the random subsystem read the tsc for event "timestamps".

2020-06-03T06:54:04Z

introduce "cpu_rnd_messybits" for use instead of nanotime in dev/rnd.c.

2020-05-31T06:23:56Z

rnd.c uses nanotime to get access to some bits that change quickly between events that it can mix into the entropy pool. it doesn't use nanotime to get a monotonically increasing set or ordered and accurate timestamps, it just wants something with bits that change. there's been discussions for years about letting rnd use a clock that's super fast to read, but not necessarily accurate, but it wasn't until recently that i figured out it wasn't interested in time at all, so things like keeping a fast clock coherent between cpu cores or correct according to ntp is unecessary. this means we can just let rnd read the cycle counters on cpus and things will be fine. cpus with cycle counters that vary in their speed and arent kept consistent between cores may even be desirable in this context. so this is the first step in converting rnd.c to reading cycle counter. it copies the nanotime backend to each arch, and they can replace it with something MD as a second step later on. djm@ suggested rnd_messybytes, but we landed on cpu_rnd_messybits. thanks to visa for his eyes. ok deraadt@ visa@ deraadt@ says he will help handle any MD fallout that occurs.

Kill biospoll/pctrpoll defines and use `seltrue' directly in cdev_*_init().

2020-05-13T08:32:43Z

While here use the kqfilter equivalent to `seltrue' to ensure both interfaces are coherent. ok visa@

Use the same inittodr()/resettodr() implementation as on arm64/armv7/sparc64

2020-04-28T12:58:27Z

and move it to the end of machdep.c. Rework the actual implementation for te MC14818 compatible RTC into something that can be used as a todr_handle. ok mpi@

Remove unused protoype.

2020-04-15T16:38:24Z

vmm(4): add IOCTL handler to sets the access protections of the ept

2020-04-08T07:39:48Z

This exposes VMM_IOC_MPROTECT_EPT which can be used by vmd to lock in physical pages. Currently, vmd just terminates the vm in case it gets a protection fault in the future. This feature is used by solo5 which uses vmm(4) as a backend hypervisor. ok mpi@ Patch from Adam Steen

vmm(4): handle cr0 writes more correctly for vmx

2020-04-08T07:32:56Z

* Switch to using vcpu->vc_vmx_cr0_fixed[1|0] to check must be 0|1 bits, rather than the cpu capabilities. * Add the checks on the new values as per the SDM 2.5 CONTROL REGISTERS. 2.1 Bits 63:32 of CR0 and CR4 are reserved and must be written with zeros. Writing a nonzero value to any of the upper 32 bits results in a general-protection exception, #GP(0). 2.2 setting the PG flag when the PE flag is clear causes a general-protection exception (#GP). 11.5.1 Cache Control Registers and Bits, Table 11-5. Cache Operating Modes 2.3 CD: 0, NW: 1, Invalid setting. Generates a general-protection exception (#GP) with an error code of 0. *. Don't alway assume, if the guest is not disabling paging, they are enabling it, check the guest is actually enabling paging. also only read cr4 when we actually need it, not right at the start. ok mpi@ Patch from Adam Steen

Take a swing at blocking Load-Value-Injection attacks against the

2020-03-11T07:27:08Z

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@

oops some snapshot tests fell in

2020-02-28T05:22:52Z