wireguard-openbsd/sys/stand, branch jd/queueboostsWireGuard implementation for the OpenBSD kernelhttps://git.zx2c4.com/wireguard-openbsd/atom/sys/stand?h=jd%2Fqueueboosts2020-06-15T14:43:57Zalign the random buffer so mdrandom() can fill it with register-width2020-06-15T14:43:57Znaddynaddy@openbsd.org2020-06-15T14:43:57Zurn:sha1:91bdb1f19a66ebd7f1edbf3def1ae6da94f394d2
writes without incurring unaligned accesses; ok deraadt@
/etc/random.seed reuse can now be detected. The stat +T bit marks the file2020-05-26T13:47:27Zderaadtderaadt@openbsd.org2020-05-26T13:47:27Zurn:sha1:e4a6744d811c9dacc6cbd14518ea6671acce58e9
(fchmod +T by bootcode, chmod 600 by /etc/rc). If the seed is reused, and
HWRNG isn't available, the kernel won't get RB_GOODSEED indication...
make loadrandom() return 0 for success, -1 for failure. While here,2020-05-25T15:49:41Zderaadtderaadt@openbsd.org2020-05-25T15:49:41Zurn:sha1:a872426c0e19cd2db852b132ac3ba4865f303e4a
relax the fstat() check because the system will have left the file
in the right mode.
ok visa kettenis
If either mdrandom() or fwrandom() return 0, set RB_GOODRANDOM2020-05-25T15:28:21Zderaadtderaadt@openbsd.org2020-05-25T15:28:21Zurn:sha1:d3cf030a52866b6d79bac7fe33be77150afed39a
ok kettenis
Adjust fwrandom() to return 0 for sucess, -1 for failure2020-05-25T14:53:57Zderaadtderaadt@openbsd.org2020-05-25T14:53:57Zurn:sha1:d4fa8acb0d6af3b6ddbd07c22e37180c5e52477fFor 32 bit systems, cast the long long used by strtoll() to unsigned long2019-12-02T01:38:06Zderaadtderaadt@openbsd.org2019-12-02T01:38:06Zurn:sha1:1f267e12cfbf98d3d6210addd62d9ec338bc61a5
and then a void * for calling the hexdump() operator
with bluhm
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@
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
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
Fix prototype of upgrade(). OK benno@2019-05-10T12:49:58Zclaudioclaudio@openbsd.org2019-05-10T12:49:58Zurn:sha1:886f00e8219261d34eaaaa76f4e7f68a86206c52