| Age | Commit message (Collapse) | Author |
|---|
|
ok deraadt@
|
|
adds kernel support for
amdgpu: vega20, raven2, renoir, navi10, navi14
inteldrm: icelake, tigerlake
Thanks to the OpenBSD Foundation for sponsoring this work, kettenis@ for
helping, patrick@ for helping adapt rockchip drm and many developers for
testing.
|
|
|
|
This allows FFS2 to be enabled. Has been in snaps for quite some days.
With and ok deraadt@
|
|
ok deraadt
|
|
ok deraadt krw
|
|
While FIDO/U2F keys were already supported by the generic uhid(4)
driver, this driver adds the first step to tighten the security of
FIDO/U2F access. Specifically, users don't need read/write access to
all USB/HID devices anymore and the driver also improves integration
with pledge(2) and unveil(2): It is pledge-friendly because it doesn't
require any ioctls to discover the device and unveil-friendly because
it uses a single /dev/fido/* directory for its device nodes.
It also allows to support FIDO/U2F in firefox without further
weakening the "sandbox" of the browser. Firefox does not have a
proper privsep design and many operations, such as U2F access, are
handled directly by the main process. This means that the browser's
"fat" main process needs direct read/write access to all USB HID
devices, at least on other operating systems. With fido(4) we can
support security keys in Firefox under OpenBSD without such a
compromise.
With this change, libfido2 stops using the ioctl to query the device
vendor/product and just assumes "OpenBSD" "fido(4)" instead. The
ioctl is still supported but there was no benefit in obtaining the
vendor product or name; it also allows to use libfido2 under pledge.
With feedback from deraadt@ and many others
OK kettenis@ djm@ and jmc@ for the manpage bits
|
|
|
|
Its last consumer is now gone and it has certainly not been used since the
introduction of PAE back in 2015.
ok kettenis@, jsg@
|
|
When PAE came back in 2015 the use of kvm86, required for SpeedStep on
such machine, got disabled. So there's no loss of functionality.
ok stsp@
|
|
ok deraadt@
|
|
device.
"just commit!" deraadt@
"looks good to me" jmatthew@
|
|
and not just ".openbsd.randomdata.retguard". Accept both in the kernel
ldscripts so that they're placed together between the __retguard_{start,end}
symbols.
Similarly, match not just ".openbsd.randomdata" but also
".openbsd.randomdata.*" to pick up other random (pun intended) items.
While here, stub in those retguard bits into all the ldscripts.
ok deraadt@
|
|
retguard and similar when profiling. However, that missed all the .S files,
as ${PROF} wasn't added when ${NORMAL_S} was converted from direct invocation
of ${AS} to instead use ${CC}. Similarly, mcount.o still had retguards
as it cannot be built with -pg. So: pass ${PROF} when compiling .S files,
and compile "no profiling" files with -fno-ret-protector on archs with
retguard.
feedback and ok mpi@ mortimer@
|
|
|
|
Use install -F to instead of cp, for fsync(2). Coupled with the new
sync(8) in the reorder_kernel script, the window for a incomplete /bsd
file on-disk due to a crash has now shrunk substantially.
Discussion with kettenis, millert and tedu
|
|
ok deraadt@
|
|
has broken the tree once again.
ok kettenis
|
|
ok deraadt@
|
|
|
|
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@
|
|
tightly-built ramdisk kernels, set the option in per-arch Makefile.inc
based upon SMALL_KERNEL
|
|
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.
|
|
|
|
comparison instructions and switch statements are being traced. This mode will
be used during fuzzing to generate even more coverage. The same mode is also
supported by FreeBSD and Linux.
Thanks to jmc@ for improving the manual bits.
ok bluhm@ visa@
|
|
We will still be able to run i386 guests on amd64 vmm.
Reasons to delete i386 vmm:
- Been broken for a while, almost no one complained.
- Had been falling out of sync from amd64 while it worked.
- If your machine has vmx, you most probably can run amd64, so why not run that?
ok deraadt@ mlarkin@
|
|
This improves timekeeping on KVM guests as it runs much better than
the virtualized acpihpet or acpitimer timecounters and the invtsc is
not always available.
Many thanks to Janne Johansson, landry@, and benno@ for testing amd64/i386.
OK mlarkin@ phessler@
|
|
and .data segments that have the X (executable) flag set when using lld.
This doesn't result in those sections being mapped executable in the bsd
kernel, but it does result in the X flag being set on those sections in
the final kernel binary, which confuses some scanning tools for (ROP)
gadgets.
Fix this by tweaking the generated gapdummy.c file that is used for
building gap.o. It now defines the .rodata section using inline asm.
This also fixes .data as it will inherit its flags from .rodata.
ok deraadt@, mortimer@
|
|
LOADADDR(.text) is only available after the description of the text
section. Instead simply use ENTRY(start) like we do on amd64. The
bootloader strips the high bits from the entry point address already,
so using the virtual address as the entry point address works.
with/ok kettenis@
|
|
ok kettenis@
|
|
ok jsg@ phessler@ kettenis@ deraadt@
|
|
armv7 and i386 with amd64.
ok guenther@
|
|
|
|
ok deraadt@ mlarkin@
|
|
Based on a submisison from Jan Klemkow.
|
|
pseudo-device, get rid of the option. Enabling kcov now requires the following
line to be added to the kernel config:
pseudo-device kcov 1
This is how pseudo devices are enabled in general. A side-effect of this change
is that dev/kcov.c will no longer be compiled by default.
Prodded by deraadt@; ok mpi@ visa@
|
|
|
|
with the syzkaller kernel fuzzer. So far, 8 distinct panics have been found and
fixed. This effort will continue.
kcov is limited to architectures using Clang as their default compiler and is
not enabled by default.
With help from mpi@, thanks!
ok kettenis@ mpi@ visa@
|
|
adapters.
"go ahead commit it" deraadt@
|
|
|
|
a custom kernel for over 20 years.
testing mlarkin@
ok deraadt@ phessler@ jca@ matthieu@
|
|
Requested by brad@
Tested by fcambus@
ok stsp@
|
|
ok guenther@, deraadt@
|
|
|
|
Requested by deraadt@
|
|
from mlarkin@
|
|
therefore all other x86 cpus must pay the performance price of the
hazard workaround until Skylake disappears from the ecosystem eventually
like 486. This returns your cpu's performance to pre-inflated performance.
ok mlarkin guenther
|
|
noticed by deraadt@ and mlarkin@
|
|
OK mlarkin@
|
|
- provide struct cpu_info_full
- prepare K-U sections
- reorganize interrupt, trap, syscall entry to use K-U trampoline
- prepare pmap for entering special mappings, the mappings are not
setup yet
This code will already trigger performance issues. We do more tlb
flushes, but we do not unmap the kernel yet. The latter
will be needed to prevent Meltdown.
from hshoexer@; input guenther@; OK mlarkin@ deraadt@
|
