wireguard-openbsd - WireGuard implementation for the OpenBSD kernel

	Commit message (Collapse)	Author	Age	Files	Lines
*	Use daddr_t and not daddr32_t in boot media.	krw	2020-12-09	1	-2/+2
\| \| \| \| \| \| \| \| \| \|	At a minimum, amd64/i386 should now boot from 4TB GPT formatted disks. More daddr32_t terminations with extreme prejudice to follow. Tested by various, in snaps for a few days. ok deraadt@
*	increment version numbers, due to recent RB_GOODSEED and fchmod +T changes	deraadt	2020-05-26	1	-2/+2
\|
*	Check outcome of loadrandom() on octeon	visa	2020-05-26	2	-11/+26
\| \| \| \| \| \| \| \| \| \|	If loadrandom() succeeds, set RB_GOODRANDOM in boothowto. To enable fchmod(), disk_open() has to mount the filesystem in writable mode. This is tricky because the filesystem might be unclean. Hence the code has to use MNT_FORCE. Input and OK deraadt@
*	Rework kernel loading with octboot(4)	visa	2020-05-26	1	-5/+45
\| \| \| \| \| \| \| \|	Load the kernel image from the filesystem upfront in rdboot and pass the loaded image to octboot(4)'s kexec call in a memory buffer. As a result, octboot(4) does not rely on a mounted filesystem. OK deraadt@
*	Pass boothowto from the bootloader to the kernel on octeon.	visa	2020-05-25	1	-8/+5
\| \| \| \|	OK deraadt@
*	this hexdump tie-in is incorrect, disable for now	deraadt	2019-12-01	1	-2/+2
\|
*	Implement a hexdump command in the boot loader. This helps to	bluhm	2019-11-28	1	-1/+4
\| \| \| \| \| \|	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 having	deraadt	2019-11-01	1	-2/+2
\| \| \| \| \|	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.randomdata	deraadt	2019-10-29	1	-2/+2
\| \| \| \| \| \| \| \| \|	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
*	Revise the way how the octeon bootloader is built. The original	visa	2019-08-04	1	-7/+3
\| \| \| \| \| \|	approach was not right, and there is still room for improvement. OK deraadt@
*	Fix fd leak that broke disk_close().	visa	2019-08-01	1	-1/+2
\|
*	Link octeon bootloader to the build.	visa	2019-07-28	1	-3/+7
\| \| \| \|	OK deraadt@
*	Fix trimming of newline.	visa	2019-07-28	1	-2/+5
\|
*	Add a bootloader for octeon.	visa	2019-07-17	7	-0/+1207
	The firmware on OCTEON machines usually does not provide an interface for accessing devices, which has made it tricky to implement an OpenBSD bootloader. To solve this device access problem, this new loader has been built on top of a small kernel. The kernel provides all the necessary devices drivers, while most of the usual bootloader logic is in a userspace program in a ramdisk. The loader program is accompanied by a special device, octboot(4). The main purpose of this device is to implement a mechanism for loading and launching kernels. The mechanism has been inspired by Linux' kexec(2) system call. The bootloader will be enabled later when it is ready for general use. Discussed with deraadt@