wireguard-openbsd/sys/arch/alpha/conf, branch jd/queueboostsWireGuard implementation for the OpenBSD kernelhttps://git.zx2c4.com/wireguard-openbsd/atom/sys/arch/alpha/conf?h=jd%2Fqueueboosts2020-05-23T06:28:29Zremove more cfb and sfb bits2020-05-23T06:28:29Zjsgjsg@openbsd.org2020-05-23T06:28:29Zurn:sha1:998fd26cd35836de5ded8468ae9e096a47a23f66remove cfb and sfb alpha tc fb drivers2020-05-23T06:17:08Zjsgjsg@openbsd.org2020-05-23T06:17:08Zurn:sha1:be87d8d3495ba17f242137e7e1e9196330faca6a
These were removed from files.alpha 1.105 in 2017 and the rcons bits
they reference were removed in 2006.
removal suggested by miod@
Add fido(4), a HID driver for FIDO/U2F security keys2019-12-17T13:08:54Zreykreyk@openbsd.org2019-12-17T13:08:54Zurn:sha1:1ba9f8e24a930839b47e1417a70ad7b6ffac57d7
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
The compiler -pg option implies -fno-ret-protector, as we want to disable2019-11-07T20:42:28Zguentherguenther@openbsd.org2019-11-07T20:42:28Zurn:sha1:9b3feccb14f903ea6e8c89b9e519c64c5caa115f
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@
Remove DST/TIMEZONE options(4) from kernel configs; ok jca@ deraadt@2019-09-04T14:29:41Zchelohacheloha@openbsd.org2019-09-04T14:29:41Zurn:sha1:0f929ac1db6ea8004de3b88b4609b5c434d84654Further improve the filesystem stability of kernel installation by KARL.2019-06-21T15:34:06Zderaadtderaadt@openbsd.org2019-06-21T15:34:06Zurn:sha1:674ee82eea834d97454b373da0a1af6b81bee24a
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
Enable ucrcom(4) on all architectures that have uslcom(4).2019-05-08T23:54:38Zketteniskettenis@openbsd.org2019-05-08T23:54:38Zurn:sha1:43aa04de7fb707cab2ee2b1475d78bb4ce6418e6
ok deraadt@
Instead of using COPTS=-Oz (and similar) in make environment to force2019-04-14T14:07:05Zderaadtderaadt@openbsd.org2019-04-14T14:07:05Zurn:sha1:9b26c7b87b6a10edf98cb84cb8dd83c03ccbd148
tightly-built ramdisk kernels, set the option in per-arch Makefile.inc
based upon SMALL_KERNEL
Enable uscom(4) where uslcom(4) is already present.2018-08-22T15:38:46Zmpimpi@openbsd.org2018-08-22T15:38:46Zurn:sha1:0de6f3d4d0bd463a2e523d5f5fcf30e59ed50521
Based on a submisison from Jan Klemkow.
prune files.* entries that refer to files not in tree2018-02-14T23:51:49Zjsgjsg@openbsd.org2018-02-14T23:51:49Zurn:sha1:4d5fab15c3352c0df3c4c7158eddec500aa07e90
ok krw@ mpi@