| Age | Commit message (Collapse) | Author |
|---|
|
mcount.c, in the same way that -fno-ret-protector is set (because
the default ret-protector is an "always" generator). This change
ensures there is never a stack protector prologue/epilogue in the
functions in that file, no matter what stack protector selection
algorithm is in play.
ok kettenis guenther
|
|
no longer needed with zlib 1.3
ok tb@
|
|
Disable -Wdeprecated-non-prototype instead of patching zlib. Upstream
plans to drop the pre-ANSI syntax soon. ok tb@ millert@
|
|
Testing by hastings@ and myself.
i386 has a media size issue, deraadt@ will sort it out.
|
|
This produces helpful flamegraphs on macppc.
With Andrew Krasavin <noiseless-ak AT yandex DOT ru>.
OK mpi
|
|
with LLVM 13.
|
|
this hides real problems that could be found at build time
ok kettenis@ visa@, ok sashan@ on amd64/i386
|
|
the asynchronous crypto API which makes progress in MP difficult.
The hardware is rarely available. They support only obsolete crypto
algorithms. Scheduling crypto tasks via PCI is probably slower
than the CPU, especailly as modern CPUs have their own accelerators.
|
|
keyboard is a pseudo device which is used to expose audio and
application launch keys. My prime motivation is to get the volume mute,
increment and decrement keys to just work on my keyboard without the
need to use usbhidaction(1).
Looks reasonable to kettenis@ mpi@ and ok jcs@
|
|
These are copies of powerpc64/conf/ld.script with some changes for
macppc. They work with both ld.bfd and ld.lld.
The ld.script fixes ld.lld. Without ld.script, lld would set the
symbol "etext" to a wrong value like 0x10000034, then ofwboot would
freeze and fail to boot the kernel. With ld.script, we PROVIDE a
correct etext.
ok kettenis@
|
|
exposing battery sensors for HID++ 2.0 devices. Most of the code is
derived from the hid-logitech-hidpp Linux driver.
Thanks to Ville Valkonen <weezeldinga at gmail dot com> for testing.
ok mglocker@
|
|
SMALL_KERNEL specific variations.
ok espie jsg
|
|
This includes ujoy_hid_is_collection() to work around limitations of
hid_is_collection() until this can be combined without fallout.
input, testing with 8bitdo controller, and ok brynet@
PS4 controller testing, fix for hid_is_collection, and ok mglocker@
|
|
Add R_PPC_ADDR24 to lld. We need R_PPC_ADDR24 for absolute branches
"ba" and "bla" in locore.S in the kernel.
In Makefile.macppc, add a gapdummy (like in Makefile.powerpc64) to
avoid an lld error. Also adapt a part of Makefile.i386, so my
powerpc64 can use clang and lld to build and link the macppc kernel.
(I didn't boot that kernel.)
My macppc can now build, link, and boot kernels with either ld.bfd or
ld.lld. Beware that kernels linked with ld.lld have at least one
problem (wrong &etext) not yet fixed.
ok kettenis@
|
|
|
|
ok tedu@ jsg@
|
|
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
|
|
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@
|
|
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.
|
|
|
|
Passes 'make release' build.
|
|
Tested by Christian Hammerschmidt.
|
|
Based on a submisison from Jan Klemkow.
|
|
ok krw@ mpi@
|
|
Fixes 'make install' when /bsd is not present for some reason.
ok rob florian, "fine with me" deraadt
|
|
Tested by & diff from Donovan Watteau.
|
|
end of rc we call reorder_kernel which creates a /obsd hard link to
the same kernel.
In the past obsd was only created when doing a manual make install in
the kernel sources.
There is no need for two backup hard links during boot, rearange the
kernel Makefiles to restore previous behaviour and thus stopping
reorder_kernel from scribbling over /obsd.
Makes muscle memory of some kernel developers work again: /obsd can
serve as a known good kernel; and there was much rejoycing...
Discussed at length with benno, rpe, phessler and tb at
p2k17.
Seems like a good idea to deraadt.
OK benno, phessler, rpe, tb
|
|
|
|
|
|
the kernel makefiles was removed which lead to C files not being re-
compiled when a dependency changed. This can lead to panics in odd
places and generally a broken system.
ok deraadt@
|
|
functionnalities are available in GENERIC.
ok jasper@, deraadt@, guenther@, dlg@
|
|
|
|
ok deraadt@, jasper@
|
|
whenever make is issued. Only do this when there are actual source changes
below /sys. This restores the behavior prior to the KARL implementation.
Problem noticed and patiently explained by mpi
implementation with a lot of help from espie
ok mpi, espie, deraadt
|
|
a partial solution to cross compiling the kernel with KARL.
OK deraadt@ a while ago
|
|
"go for it" deraadt@
|
|
|
|
without src and comp work. That is what we've designed for, but since
we always have src and comp on our systems it is so easy to slide...
problem first noted by rpe.
|
|
architectures we must also link against a gapdummy.o to repair the ABI
of the resulting .o file. Woe is me.
Also repair install: target to update the linkkit & hash when a kernel
is installed.
ok rpe tb mlarkin and tested by others also
|
|
run so that this locore0.o is always at the start of the executable.
But randomize the link order of all other .o files in the kernel, so
that their exec/rodata/data/bss segments land all over the place.
As a result, the internal layout of every newly build bsd kernel is
different from past kernels. Internal relative offsets are not known
to an outside attacker. The only known offsets are in the startup code
(which will be gone when it is smashed).
The bootstrap code unmapping or smashing isn't done yet, and there is
some potential for more bits from locore.S to move to locore0.S
|
|
infrastructure that is coming requires an architecture to carry such a
file.
|
|
fiction participating only in the linkphase.
tricks from rpe and espie
|
|
Otherwise owner of /bsd could be the build user with permissions
inherited from the compile directory.
OK deraadt@ tb@
|
|
Prying eyes cannot look at the kernels in the compile directory.
ok tb rpe, kernel developers seem unimpacted
|
