wireguard-openbsd/sys/arch/amd64/stand/boot, branch jd/queueboostsWireGuard implementation for the OpenBSD kernelhttps://git.zx2c4.com/wireguard-openbsd/atom/sys/arch/amd64/stand/boot?h=jd%2Fqueueboosts2020-06-14T16:06:25Zcrank version number2020-06-14T16:06:25Zderaadtderaadt@openbsd.org2020-06-14T16:06:25Zurn:sha1:29c02c14e09366e368ddf37ede6a9862fbfa2d6brewrite mdrandom() in C. previously this XOR'd against rdrand if available,2020-06-14T16:00:08Zderaadtderaadt@openbsd.org2020-06-14T16:00:08Zurn:sha1:55f8664c3cb6c3d3b4f4fd806d3cc0a0106e6ba9
and alternatively XOR'd against TSC. now always run both sequences, and
also support rdseed as a third procedure.
ok kettenis naddy
increment version numbers, due to recent RB_GOODSEED and fchmod +T changes2020-05-26T14:00:40Zderaadtderaadt@openbsd.org2020-05-26T14:00:40Zurn:sha1:ed5a52b6bdf7c7f007d222e270b64343a6f85fc8Allow amd64 boot(8) and friends to read from an ffs2 filesystem.2020-03-05T16:36:30Zottootto@openbsd.org2020-03-05T16:36:30Zurn:sha1:17a1c5d6e306acda7fdf00eee21334d5e9e70054
Also enable ffs2 for floppy, so that its kernel kan access ffs2. ok deraadt@
The boot loader allows to inspect memory with the hexdump command.2019-12-23T12:44:34Zbluhmbluhm@openbsd.org2019-12-23T12:44:34Zurn:sha1:8f2953bf9f05b1a464145c550d46b7be6a4bc4ab
Document the new feature in boot(8) man page.
OK jmc@ 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@
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
Improve previous2019-10-20T22:15:07Zknkn@openbsd.org2019-10-20T22:15:07Zurn:sha1:0ac7466ceddfd799ea896c5da39bfb7f1472401e
From and OK jmc
Document "set db_console 0|1"2019-10-20T16:13:35Zknkn@openbsd.org2019-10-20T16:13:35Zurn:sha1:5604dfeda0d6d1ceea03d64fae8eab6c1ebacbd1
OK deraadt
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