wireguard-openbsd/sbin/unwind, branch jd/queueboostsWireGuard implementation for the OpenBSD kernelhttps://git.zx2c4.com/wireguard-openbsd/atom/sbin/unwind?h=jd%2Fqueueboosts2020-05-25T16:52:15ZDo not log "startup" to syslog.2020-05-25T16:52:15Zflorianflorian@openbsd.org2020-05-25T16:52:15Zurn:sha1:04a70a4bd8faab86c30825b5ba9aa7200597fa46
slaacd and unwind start very early in the boot process and syslog is
not fully available yet so these messages tend to get lost.
But they are also not particularly useful.
Prompted by a report by Jason Mader on bugs@
OK deraadt, claudio, bluhm
Note that this code has been copied around to all our privsep daemons
and also lives in usr.sbin. Leave it alone there because multiple people
said they find it useful for those daemons.
sync libunbound fixes from unbound, ok florian@2020-05-19T16:56:28Zsthensthen@openbsd.org2020-05-19T16:56:28Zurn:sha1:5a7d75e635be6d887aa526e2450059ba08aae2a1sockaddr_rtdns does not guarantee alignment of the buffer. So first2020-05-10T06:44:07Zottootto@openbsd.org2020-05-10T06:44:07Zurn:sha1:5bf84caaa4c940bb65ae5789904e9cf23f5febfd
memcpy the address into a local var before comparing it with code
that reads ints using int *. at least sparc64 and landisk suffer from this.
with and ok jca@
Use a union to ensure cmsg buffer is properly aligned2020-05-08T20:11:00Zjcajca@openbsd.org2020-05-08T20:11:00Zurn:sha1:3d4dbd371cf272f2699c457f068f2127bb3e4e71
Fixes a crash on landisk (strict alignement arch) reported by otto@
ok deraadt@ otto@
unwind(8) is supposed to work in all situations, it no longer2020-04-21T17:03:44Zflorianflorian@openbsd.org2020-04-21T17:03:44Zurn:sha1:259cc53325414b057b4af8fc42a06cf1393628d2
closes its service port when resolving is not working to give asr(3) a
chance (because it falls back to asr(3) internally)
Therefore it is ok to only list 127.0.0.1 in /etc/resolv.conf.
Triggered by a question from Frantisek Holop.
OK benno
Declare lz_enter_rr_into_zone() static, it's only used in2020-03-23T08:38:49Zflorianflorian@openbsd.org2020-03-23T08:38:49Zurn:sha1:255203d5a21bf929292fa16e2209f3caa07bb097
this file. Pointed out by clang with -Wmissing-prototypes
Fix prototype.2020-03-23T08:38:15Zflorianflorian@openbsd.org2020-03-23T08:38:15Zurn:sha1:8156a4bf1f02f826c6eb143796c2808cbcdfd943
Pointed out by clang with -Wstrict-prototypes
Update to libunbound 1.10.02020-03-23T08:37:26Zflorianflorian@openbsd.org2020-03-23T08:37:26Zurn:sha1:d32eb43c98fe133df5eab7dc88533129ee17734e
Heavy lifting by sthen in unbound(8)
Tested by benno and matthieu
Return when create_solver() returns NULL to prevent null pointer dereference2020-03-19T19:27:21Ztobhetobhe@openbsd.org2020-03-19T19:27:21Zurn:sha1:37185839aa875dc4a720a27054894f07046ec94a
in 'resolvers[type]->state = state'.
ok florian@
We are not correctly upgrading from "UNKNOWN" to "VALIDATING"2020-01-28T21:11:06Zflorianflorian@openbsd.org2020-01-28T21:11:06Zurn:sha1:23b78d59dd06c749764286c494b6da7648557f69
resulting in a "fatal in resolver: wrong unified cache set on
resolver".
I believe this happens because we are using an UNKNOWN resolving
strategy to resolve queries.
Disable the upgrade logic for now and always construct a fresh
resolver context and set the unified context on it before any cache
gets allocated. This causes a bit of memory churn on startup and when
changing networks, but better than a crashing unwind.
First observed by deraadt