wireguard-openbsd/sys/arch/alpha/stand, branch jd/queueboostsWireGuard implementation for the OpenBSD kernelhttps://git.zx2c4.com/wireguard-openbsd/atom/sys/arch/alpha/stand?h=jd%2Fqueueboosts2020-05-26T13:47:27Z/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
Pass boothowto from bootblock to kernel2020-05-25T15:00:22Zderaadtderaadt@openbsd.org2020-05-25T15:00:22Zurn:sha1:c2afdefe37f83deee120e110e5e299de81813289Add support for write operations to diskstrategy().2020-05-25T02:04:48Zderaadtderaadt@openbsd.org2020-05-25T02:04:48Zurn:sha1:77b219e0ed44c82d1eade27be3a0a0910c0035b1 ce examples of "Ar arg Ar arg" with "Ar arg arg" and stop the spread;2020-04-23T21:28:08Zjmcjmc@openbsd.org2020-04-23T21:28:08Zurn:sha1:48c01a1f20ca923b4fd42e96d16e47b607f8e4ebAllow alpha boot(8) to read from an ffs2 filesystem and adapt its2020-03-11T09:59:31Zottootto@openbsd.org2020-03-11T09:59:31Zurn:sha1:108bc87a7a9d19defc10c5f35a081db90d6e0e96
custom installboot to deal with ffs2. While there, fix the partition
read code to deal with offsets > 2G; ok deraadt@
Remove unused test program.2019-12-01T03:48:48Zvisavisa@openbsd.org2019-12-01T03:48:48Zurn:sha1:5f5bc776edd179aaaf0c71dde976677d85cdf95b
OK deraadt@
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
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