wireguard-openbsd/sys/lib/libsa, branch master WireGuard implementation for the OpenBSD kernel https://git.zx2c4.com/wireguard-openbsd/atom/sys/lib/libsa?h=master 2021-03-12T10:22:46Z spelling 2021-03-12T10:22:46Z jsg jsg@openbsd.org 2021-03-12T10:22:46Z urn:sha1:84f3acfde2a7e7d22afae1b5e404e34b9403abc7 Use daddr_t and not daddr32_t in boot media. 2020-12-09T18:10:17Z krw krw@openbsd.org 2020-12-09T18:10:17Z urn:sha1:3e58d19e89b8645264ea84c2f797d77942ef298e 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@ Remove an unneeded variable. 2020-10-26T04:04:31Z visa visa@openbsd.org 2020-10-26T04:04:31Z urn:sha1:174697beef01c2f6add49ad98dbc1dc953740c31 OK kettenis@ Fix a warning false positive from clang 10. 2020-07-09T19:17:19Z millert millert@openbsd.org 2020-07-09T19:17:19Z urn:sha1:04a2240bd8f465bcae6b595d912af3e2965856de blf_enc() takes a number of 64-bit blocks to encrypt, but using sizeof(uint64_t) in the calculation triggers a warning from clang 10 because the actual data type is uint32_t. Pass BCRYPT_WORDS / 2 for the number of blocks like libc bcrypt(3) does. OK kettenis@ If we pass a packet length larger than 2^16, we should panic() instead 2020-05-19T12:54:37Z patrick patrick@openbsd.org 2020-05-19T12:54:37Z urn:sha1:396ee6d6b62cd4725fd412b6e857e55aee684d35 of returning -1. With a return type of u_int16_t, -1 is not different to a valid checksum. For incoming packets, the header lengths don't exceed that size anyway, but for outgoing packets it's better to see if our bootloader crafts a broken one. Discussed with gerhard@ ok deraadt@ procter@ Sync in_cksum.c to the same version ospfd has. This fixes problems 2020-05-18T17:01:02Z patrick patrick@openbsd.org 2020-05-18T17:01:02Z urn:sha1:419596d7e7d9396d7ff0a802278e9a2db9b17f1e with odd packet lengths, which can happen when using TFTP to load a file with an odd length. ospfd actually took dvmrpd's version in 2006 to fix the same issue, and both daemons implementations are the same. For the bootloader we keep the consts from the previous version and replace the fatal with a print and return. ok deraadt@ Next step in prepping for ffs2 installs: introduce a new install script var 2020-02-29T07:31:34Z otto otto@openbsd.org 2020-02-29T07:31:34Z urn:sha1:6221c7eaa9bd32362d70d40c1870fbf4a4bf81cf MDFSOPT and add a missing prototype. Add an element to the marks array to store the virtual address of the 2019-11-29T20:53:13Z kettenis kettenis@openbsd.org 2019-11-29T20:53:13Z urn:sha1:934484026c7a2904fb164ecd78330ff78899d549 entry point. ok mlarkin@, deraadt@ Implement a hexdump command in the boot loader. This helps to 2019-11-28T00:17:10Z bluhm bluhm@openbsd.org 2019-11-28T00:17:10Z urn:sha1:3fbdbb315f0b99e633dc16e3d2b7a673b2569d3d 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 2019-11-01T20:54:52Z deraadt deraadt@openbsd.org 2019-11-01T20:54:52Z urn:sha1:b4bcf6304410501bfbe0df1a65ef5b432faa8426 it larger than RC4STATE. A long discussion ensued. In conclusion all entropy inputs are either satisfactory enough, or just as shitty at 512.