summaryrefslogtreecommitdiffstats
path: root/sys/arch/amd64 (follow)
Commit message (Collapse)AuthorAgeFilesLines
* vmm(4): Pass through CPUID function/leaf 0x16 for processor speed.mlarkin2019-06-131-8/+6
| | | | ok deraadt, pd, phessler
* Remove unused scheduler related definitions.mpi2019-06-111-4/+1
| | | | ok visa@
* Allow memory that isn't (32-bit) DMA reachable when loading a map that waskettenis2019-06-091-3/+5
| | | | | | created with the BUS_DMA_64BIT flag. ok jsg@
* When loading intel microcode in the non-efi case, error if the file isjsg2019-06-082-4/+4
| | | | | | | larger than 256KB not 128KB to cope with the 06-8e-09 microcode which is currently 193KB. Reported and tested by Paul de Weerd. Matches a diff from claudio@
* add ukspan(4), a driver for the Keyspan USA19HS USB serial adapterjcs2019-06-071-1/+3
| | | | written by Cody Cutler <ccutler at csail.mit.edu>
* Stop promoting the TSC as a high quality timecounter on MULTIPROCESSORkettenis2019-06-061-1/+5
| | | | | | | | | systems. There is no guarantee that the TSCs on different cores are synchronized when the OpenBSD kernel boots and we don't have code to synchronize them ourselves. This affects both AMD and Intel CPUs and even cores on the same socket can by out of sync. ok deraadt@, sthen@
* Refactor the MAP_STACK feature, and introduce another similar variation:deraadt2019-06-011-25/+5
| | | | | | | | | Lookup the address that a syscall instruction is executed from, and kill the process if that page is writeable. This brings an aspect of W^X behaviour to W|X mappings (in JITs not yet adapted to W^X). The goal is to remove simple attack methods and force use of ret2libc or other more complicated means. ok kettenis stefan visa
* Use two 32-bit writes instead of a single 64-bit write to write thekettenis2019-05-301-2/+3
| | | | | | | | | message address into an MSI-X table entry. The RTL8168/RTL8111 hardware does not respond to 64-bit access (reads return all-ones, writes are ignored) and the PCI specification documents separate 32-bit "DWORD" fields for message address and message upper address. ok mlarkin@, jmatthew@
* Correct the test for when the L1TF vulnerablity has been mitigated viaguenther2019-05-281-4/+9
| | | | | | | either hardware update (RDCL_NO) or our being nested in a VM which is handling the flushing via the L1D_FLUSH MSR. ok mlarkin@
* Skip doing MDS mitigation on vmm entry if the new firmware is present,guenther2019-05-281-5/+14
| | | | | | as it enhances the L1D_FLUSH MSR to flush MDS too ok mlarkin@
* Cleanup some bootloader codemlarkin2019-05-281-27/+22
| | | | | | | | | Refactoring to remove 'long_kernel' variable and consistent use of 'entry' and 'marks[MARK_ENTRY]'. Prompted by guenther@. No functional change. tested by jca@ and myself ok guenther@, kettenis@
* Remove a 15 year old XXX commentmlarkin2019-05-281-2/+1
|
* zap reference to non-existent function in a commentjasper2019-05-231-5/+2
| | | | ok mpi@
* Allow loading of bigger ucode. This implementation uses the UEFI memorykettenis2019-05-221-5/+12
| | | | | | | | | | allocation service to allocate a block of memory below 16MB such that there is no risk of overwriting it when the bootloader moves the kernel in place. It removes the 128k limit that was previously there. Based on an earlier diff by patrick@ ok mlarkin@
* add amdgpu from linux 4.19.44 for recent AMD Radeon partsjsg2019-05-212-3/+34
| | | | | | | committing now so this can be worked on in tree Thanks to the OpenBSD Foundation for sponsoring this work and kettenis@ for helping.
* Both FreeBSD and I appear to have been confused by intel's deep-dive doc:guenther2019-05-181-3/+2
| | | | | | | | the RDCL_NO bit of the ARCH_CAPA msr only indicates one of the MDS subissues is mitigated; only the MDS_NO bit indicates they're all mitigated. ok jsg@ mlarkin@
* Oops, forgot to include a copyright year when originally addedguenther2019-05-171-2/+2
|
* Mitigate Intel's Microarchitectural Data Sampling vulnerability.guenther2019-05-1714-19/+397
| | | | | | | | | | | | | | | | 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@
* Add support to the BIOS bootloader for random kernel base VAmlarkin2019-05-159-27/+380
| | | | | | | | This diff adds support to be able to load a randomly linked kernel VA (subject to some range restrictions). This change has been in snaps for a few days without any fallout. ok deraadt@
* vmm: add host side pvclockpd2019-05-132-21/+89
| | | | | | | | | Emulate kvm pvclock in vmm(4). Compatible with pvclock(4) in OpenBSD. Linux does not attach to this (yet). Fixes by reyk@ and tested extensively by reyk@, tb@ and phessler@ ok mlarkin@ phessler@ reyk@
* Delete cpu_idle_{enter,leave}_fcn() as unused. Add RETGUARD checks toguenther2019-05-123-13/+8
| | | | | | cpu_idle_cycle() ok mpi@ kettenis@
* s/availible/available/guenther2019-05-121-2/+2
|
* vmm: add a x86 page table walkerpd2019-05-122-2/+158
| | | | | | | | | | Add a first cut of x86 page table walker to vmd(8) and vmm(4). This function is not used right now but is a building block for future features like HPET, OUTSB and INSB emulation, nested virtualisation support, etc. With help from Mike Larkin ok mlarkin@
* whitespace removalmlarkin2019-05-111-3/+3
|
* whitespace removalmlarkin2019-05-111-3/+3
|
* whitespace removalmlarkin2019-05-111-3/+3
|
* Further cleanup of efi32/64.mlarkin2019-05-1114-438/+14
| | | | | | Removes some code and files not needed by efi32 and efi64. ok guenther
* Refactor efiboot into 32 and 64 bit copies.mlarkin2019-05-1128-0/+4378
| | | | | | | | Make 2 separate efiboots, one for 32 bit and one for 64 bit to allow us to remove lots of #ifdef code. Needed to ease the development effort for random-VA linked kernels ok tedu, deraadt
* Refactor efiboot into 32 and 64 bit copies.mlarkin2019-05-1128-0/+4382
| | | | | | | | Make 2 separate efiboots, one for 32 bit and one for 64 bit to allow us to remove lots of #ifdef code. Needed to ease the development effort for random-VA linked kernels ok tedu, deraadt
* Disentangle #ifdef EFIBOOT.mlarkin2019-05-1013-188/+1169
| | | | | | | | Separate out files used by both BIOS and EFI boot modes. These files had many #ifdef EFIBOOT code paths that make it difficult to move forward with changes needed to support random base VA linked kernels. ok deraadt@
* vmm: handle some unhandled exits for SVMpd2019-05-101-2/+15
| | | | | | | | There were some exits for instructions that were unhandled and caused the guest to terminate if it tried to execute them. We now inject a #ud for those. Also intercept and #ud RDTSCP and INVLPGA instructions. ok mlarkin@
* Enable ucrcom(4) on all architectures that have uslcom(4).kettenis2019-05-081-1/+3
| | | | ok deraadt@
* Add support for the EFI Random Number Generator Protocol and use it to XORkettenis2019-05-053-5/+92
| | | | | | random data into the buffer that we feed the kernel. ok deraadt@, mlarkin@
* let users try mcx(4)deraadt2019-05-042-2/+4
|
* Improve the interaction between efifb(4), inteldrm(4) and radeondrm(4)kettenis2019-05-044-24/+59
| | | | | | | | | | | | | | | | when we have a serial console by introducing the notion of a "primary" graphics device. The primary graphics device is the one set up and used by firmware (BIOS, UEFI). The goal is to make sure that wsdisplay0 and drm0 reliably attach to the primary graphics device such that X works out of the box even if you have multiple cards or if you are using a serial console. This also fixes the situation where inteldrm(4) or radeondrm(4) would take over the console on UEFI systems even if the kernel was booted with a serial console. ok jsg@
* Fix vmm_support.S compilation error with gcc 8.3mlarkin2019-05-021-2/+2
| | | | ok deraadt
* Add a check to tftp_open() that we are actually opening a TFTP device.naddy2019-04-252-2/+15
| | | | | | | | | | When reading a file from a non-TFTP device, clear the bootmac variable to prevent the kernel from going into netboot mode. This allows loading a kernel from a disk device after having booted efiboot from PXE. style tweak and ok kettenis@
* Style tweaks:guenther2019-04-241-35/+33
| | | | | | | | - use NULL for pointer comparisons and assignments. - in level comparisons, use PTP_LEVELS instead of magic constants - eliminate some superfluous variables in pmap_free_ptp() ok mlarkin@
* Copy cache-control bits from U+K to U-K entry in pmap_enter_special()guenther2019-04-232-5/+5
| | | | | | in a generic way, correcting the handling of the LAPIC page. ok mlarkin@
* vmm(4): flush guest TLB entries if guest disables paging. While thismlarkin2019-04-221-3/+17
| | | | | | | | | | behaviour is not mandatory, the SDM says a CPU "may" do this. Better to be safe than sorry. A similar treatment will be needed for SVM, and for the cases where the host CPU does not have VPIDs/ASIDs. Those will be committed separately. Original diff from Guillaume Pagnoux, thanks!
* vmm(4): remove a debug printf that was causing lock issues (it was beingmlarkin2019-04-221-3/+1
| | | | called from an IPI routine).
* Revert enabling VMM_DEBUG which slipped through the previous commit.kn2019-04-201-2/+2
| | | | | | Fixes panic on `vmctl start foo'. OK tedu deraadt
* When copying the EFI-stored kernel to the correct operating location,deraadt2019-04-201-2/+2
| | | | use memmove. We don't know whether EFI allocated overlapping memory.
* libsa's memcpy() is actually memmove(). make a proper memmove(), and givederaadt2019-04-204-8/+8
| | | | memcpy() correct behaviour. This also brings the bcopy() macro into line.
* vmm(4): whitespace fixmlarkin2019-04-181-9/+9
|
* Instead of using COPTS=-Oz (and similar) in make environment to forcederaadt2019-04-141-1/+2
| | | | | tightly-built ramdisk kernels, set the option in per-arch Makefile.inc based upon SMALL_KERNEL
* Update shared drm code, inteldrm(4) and radeondrm(4) from linux 4.4 tojsg2019-04-141-2/+4
| | | | | | | | | | | | | | | | | | | linux 4.19.34. Adds support for more Intel hardware: Broxton/Apollo Lake (was is_preliminary in 4.4) Amber Lake (another Kaby Lake refresh) Gemini Lake Coffee Lake Whiskey Lake Cannon Lake (though no hardware with Intel graphics ever shipped) Ice Lake (alpha support, hardware not released) This does not add support for new radeon hardware on the AMD side as newer radeons have a different kernel driver (amdgpu). Thanks to the OpenBSD Foundation for sponsoring this work, kettenis@ for helping and a bunch of other developers for testing.
* crank versionsderaadt2019-04-104-8/+8
|
* change marks[] array to uint64_t, so the code can track full 64-bitderaadt2019-04-102-4/+4
| | | | | details from the ELF header instead of faking it. Proposal from mlarkin, tested on most architectures already
* crank version; looks good deraadtflorian2019-04-084-8/+8
|
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.