wireguard-openbsd/sys/lib/libsa, branch jd/queueboostsWireGuard implementation for the OpenBSD kernelhttps://git.zx2c4.com/wireguard-openbsd/atom/sys/lib/libsa?h=jd%2Fqueueboosts2020-05-19T12:54:37ZIf we pass a packet length larger than 2^16, we should panic() instead2020-05-19T12:54:37Zpatrickpatrick@openbsd.org2020-05-19T12:54:37Zurn:sha1:396ee6d6b62cd4725fd412b6e857e55aee684d35
of returning -1. With a return type of u_int16_t, -1 is not different
to a valid checksum. For incoming packets, the header lengths don't
exceed that size anyway, but for outgoing packets it's better to see
if our bootloader crafts a broken one.
Discussed with gerhard@
ok deraadt@ procter@
Sync in_cksum.c to the same version ospfd has. This fixes problems2020-05-18T17:01:02Zpatrickpatrick@openbsd.org2020-05-18T17:01:02Zurn:sha1:419596d7e7d9396d7ff0a802278e9a2db9b17f1e
with odd packet lengths, which can happen when using TFTP to load
a file with an odd length. ospfd actually took dvmrpd's version
in 2006 to fix the same issue, and both daemons implementations are
the same. For the bootloader we keep the consts from the previous
version and replace the fatal with a print and return.
ok deraadt@
Next step in prepping for ffs2 installs: introduce a new install script var2020-02-29T07:31:34Zottootto@openbsd.org2020-02-29T07:31:34Zurn:sha1:6221c7eaa9bd32362d70d40c1870fbf4a4bf81cf
MDFSOPT and add a missing prototype.
Add an element to the marks array to store the virtual address of the2019-11-29T20:53:13Zketteniskettenis@openbsd.org2019-11-29T20:53:13Zurn:sha1:934484026c7a2904fb164ecd78330ff78899d549
entry point.
ok mlarkin@, deraadt@
Implement a hexdump command in the boot loader. This helps to2019-11-28T00:17:10Zbluhmbluhm@openbsd.org2019-11-28T00:17:10Zurn:sha1:3fbdbb315f0b99e633dc16e3d2b7a673b2569d3d
inspect the memory layout that the firmware has created. It is
especially useful for UEFI debugging.
OK deraadt@ kettenis@
Reduce BOOTRANDOM_MAX to 256. naddy pointed out there's no point having2019-11-01T20:54:52Zderaadtderaadt@openbsd.org2019-11-01T20:54:52Zurn:sha1:b4bcf6304410501bfbe0df1a65ef5b432faa8426
it larger than RC4STATE. A long discussion ensued. In conclusion all
entropy inputs are either satisfactory enough, or just as shitty at 512.
Use arc4 to bit-spread the 512-byte random buffer over the .openbsd.randomdata2019-10-29T02:55:49Zderaadtderaadt@openbsd.org2019-10-29T02:55:49Zurn:sha1:f65494e6b175686dd7c3956310013295142d0607
section, which has grown a fair bit with the introduction of retguard.
Mortimer discovered the repeated 512-byte sequence as retguard keys, and
this resolves the issue. (Chacha does not fit on the media, so 1.5K early
drop RC4 is hopefully sufficient in our KARL link universe)
Version crank the bootblocks. sysupgrade -s will install new bootblocks.
ok djm mortimer
add arc4 cipher to the bootblocks2019-10-29T02:51:17Zderaadtderaadt@openbsd.org2019-10-29T02:51:17Zurn:sha1:fe753764fccdc80659ae97ffe586b7ff7d9c28ba
ok djm mortimer
In the bootblocks, after discovering and opening /bsd.upgrade, fchmod -x2019-08-03T15:22:17Zderaadtderaadt@openbsd.org2019-08-03T15:22:17Zurn:sha1:044dcf883ed02b1363c7ba7b3bffa021c5f0e0e7
so the file cannot be re-executed upon the next boot. This provides a
stronger one-shot-upgrade model than the upgrade script's rm /bsd.upgrade.
Now various forms of upgrade failure will reboot into /bsd, which is probably
more recoverable. Performing fchmod -x depends on (1) use of MI boot.c
(not alpha/macppc/sparc64/sgi/octeon) and (2) "can write blocks" functionality
in the IO layer. Most architectures have this support now.
Two diagnostics "fchmod a-x %s: failed" and "/bsd.upgrade is not u+x" will
remain in the tree while refinements happen for some of the laggard
architectures.
based upon a discussion florian
tested in snapshots for more than a week without any complaints
we have never built without %b support2019-05-11T16:56:47Zderaadtderaadt@openbsd.org2019-05-11T16:56:47Zurn:sha1:48789c6b3cc6d5509061289b43f25a60f25906ef