wireguard-openbsd/sys/stand/boot/boot.c, branch jd/simplify-queueingWireGuard implementation for the OpenBSD kernelhttps://git.zx2c4.com/wireguard-openbsd/atom/sys/stand/boot/boot.c?h=jd%2Fsimplify-queueing2020-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
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
Unbreak "boot bsd.up" line in /etc/boot.conf2019-04-10T19:41:03Zflorianflorian@openbsd.org2019-04-10T19:41:03Zurn:sha1:3642b21172b7bfac6d68b8419bc035f19e5925a9
Found the hard way by Raf Czlonka (rczlonka AT gmail), thanks!
OK deraadt
change marks[] array to uint64_t, so the code can track full 64-bit2019-04-10T04:17:31Zderaadtderaadt@openbsd.org2019-04-10T04:17:31Zurn:sha1:2340cfa57962bd12069f312342c641006c968c28
details from the ELF header instead of faking it.
Proposal from mlarkin, tested on most architectures already
Detect /bsd.upgrade kernel and boot it if present instead of default2019-04-08T13:55:46Zflorianflorian@openbsd.org2019-04-08T13:55:46Zurn:sha1:4eb8cda666a7a5e17c3b5bb32613e7aa022840e0
/bsd. To be used for unattended upgrades in the future.
Idea & OK deraadt
Add a hook to use a firmware-supplied random function in addition to the2018-04-08T13:24:36Zketteniskettenis@openbsd.org2018-04-08T13:24:36Zurn:sha1:d975447ccae4114c8837c6b794f3e6b51f8ad53b
MD-supplied random function to insert entropy into the kernel.
ok deraadt@