wireguard-openbsd/sys/arch/amd64/stand/libsa/biosdev.c, branch jd/queueboostsWireGuard implementation for the OpenBSD kernelhttps://git.zx2c4.com/wireguard-openbsd/atom/sys/arch/amd64/stand/libsa/biosdev.c?h=jd%2Fqueueboosts2018-12-16T08:33:16ZAvoid using a too big bounce buffer by splitting up large reads. Allows2018-12-16T08:33:16Zottootto@openbsd.org2018-12-16T08:33:16Zurn:sha1:6ab058fbe2fceafdb56e1cea089b1952bf618936
for booting using large (64k) blocksize filesystems. ok tedu@
Retry on incorrect passphrase for softraid crypto boot.2018-08-10T16:41:35Zjsingjsing@openbsd.org2018-08-10T16:41:35Zurn:sha1:27bea9a3c7fdba43cfa7c5fb6f268efe98f7720b
Historically, the softraid crypto support in the boot loaders has only
given one attempt to provide the correct passphrase. There were a
few reasons for this, including the fact that pkcs5_pbkdf2() allows an
empty passphrase and that returning EPERM allowed for another attempt.
With the event of KARL and the need for bsd.booted with hibernate resumption,
this becomes much more of an issue - if you get the passphrase wrong you
fail to resume. There are also other situations like using /etc/boot.conf
to switch serial console, but an incorrect passphrase results in the config
not being read. Also, bcrypt_pbkdf() does not permit empty passphrases.
This reworks the softraid crypto support in the boot loaders so that it
loops requesting a valid passphrase until one is provided, or an empty
passphrase is entered (at which point it will abort).
ok mortimer@ tb@
Check the hibernation signature for softraid disks and select valid bsd2017-07-21T01:21:42Zyasuokayasuoka@openbsd.org2017-07-21T01:21:42Zurn:sha1:6ce082ffda5e581dc8fc2743e66be9547215be6f
for unhibernation. reported by Natasha Kerensikova. tested by Theo Buehler.
ok deraadt
Fix a bug in the bounce buffer handling of BIOS disk I/O.2016-09-18T15:13:10Zjsingjsing@openbsd.org2016-09-18T15:13:10Zurn:sha1:be4b99ebbc6baf245618779f9ab265795347c75e
Currently, if a buffer crosses a 64KB boundary, a bounce buffer is
allocated, however it is assumed that this new buffer does not cross the
64KB boundary. In the case of i386 fdboot, it just so happens that (due to
the size of fdboot and heap allocations) UFS gets allocated a 4KB buffer
that crosses a 64KB boundary, then biosd_io() allocates a bounce buffer,
which also crosses a 64KB boundary. At this point the BIOS gets grumpy and
refuses to read from the disk.
Further clean up to come from tom@.
Switch amd64 to libsa MI softraid.2016-09-11T17:51:21Zjsingjsing@openbsd.org2016-09-11T17:51:21Zurn:sha1:e876def93a7396ebf9f0ccc15a64f5183a0895f4Rename softraid boot files, which are currently in an MD location. This2016-09-11T15:54:11Zjsingjsing@openbsd.org2016-09-11T15:54:11Zurn:sha1:65f4a3c79f6fe3d16cdebd7c796a7c9cc671dfe6
will allow us to bring in a MI softraid.{c,h} in lib/libsa.
Use DOS_LABELSECTOR rather than LABELSECTOR to indicate offset into an2015-10-01T20:28:12Zkrwkrw@openbsd.org2015-10-01T20:28:12Zurn:sha1:9e746c3946514232fd2b3fd0e4561d1a6713cd00
OpenBSD partition when accessing the disklabel. For these files both
are '1', but this makes the usage consistent across all archs.
ok guenther@ miod@
Remove yet more blinding whitespace.2015-10-01T16:16:23Zkrwkrw@openbsd.org2015-10-01T16:16:23Zurn:sha1:70aaba56851fe4bb1eedda4398d4c773ced754b7Remove more blinding trailing whitespace.2015-10-01T16:08:19Zkrwkrw@openbsd.org2015-10-01T16:08:19Zurn:sha1:da1a53a868a44e8251cd0d6187d38bc5a5db1570trivial "if(x) free(x)" replacement by "free(x)"2015-09-19T21:07:04Zsemariesemarie@openbsd.org2015-09-19T21:07:04Zurn:sha1:11db8caaadb72556a4c48c0d3927c4fa7c9ff197
ok miod@