wireguard-openbsd/libexec/ld.so/loader.c, branch jd/queueboosts WireGuard implementation for the OpenBSD kernel https://git.zx2c4.com/wireguard-openbsd/atom/libexec/ld.so/loader.c?h=jd%2Fqueueboosts 2019-12-17T03:16:07Z Don't look up env variables until we know we'll trust them. Otherwise, 2019-12-17T03:16:07Z guenther guenther@openbsd.org 2019-12-17T03:16:07Z urn:sha1:4b65c70c5e05dc7a3d5ef502a5b4dc938ecf3bc5 just delete them without looking. ok millert@ ld.so may fail to remove the LD_LIBRARY_PATH environment variable for 2019-12-11T18:27:54Z millert millert@openbsd.org 2019-12-11T18:27:54Z urn:sha1:eee3c75f9abd5ea51e066dd0fe6b1efa470e4d0c set-user-ID and set-group-ID executables in low memory conditions. Reported by Qualys Disable ltrace for objects linked with -znow, as at least on amd64, linking 2019-12-07T22:57:47Z guenther guenther@openbsd.org 2019-12-07T22:57:47Z urn:sha1:d9337de30c60a295621aec3876b442e235b05c93 that was deletes the lazy relocation trampoline which ltrace currently depends on problem reported by tb@ directional feedback kettenis@ ok mpi@ Convert the child_list member from a linked list to a vector. 2019-10-04T17:42:16Z guenther guenther@openbsd.org 2019-10-04T17:42:16Z urn:sha1:d937a926c9252887882b8b91c1222f18558110b8 ok mpi@ Use a better algorithm for calculating the grpsym library order. 2019-10-03T06:10:53Z guenther guenther@openbsd.org 2019-10-03T06:10:53Z urn:sha1:bae526eef07debf08a1636a7605964027dc70fd0 The existing code did a full recursive walk for O(horrible). Instead, keep a single list of nodes plus the index of the first node whose children haven't been scanned; lookup until that index catches the end, appending the unscanned children of the node at the index. This also makes the grpsym list order match that calculated by FreeBSD and glibc in dependency trees with inconsistent ordering of dependent libs. To make this easier and more cache friendly, convert grpsym_list to a vector: the size is bounded by the number of objects currently loaded. Other, related fixes: * increment the grpsym generation number _after_ pushing the loading object onto its grpsym list, to avoid double counting it * increment the grpsym generation number when building the grpsym list for an already loaded object that's being dlopen()ed, to avoid incomplete grpsym lists * use a more accurate test of whether an object already has a grpsym list Prompted by a diff from Nathanael Rensen (nathanael (at) list.polymorpheus.com) that pointed to _dl_cache_grpsym_list() as a performance bottleneck. Much proding from robert@, sthen@, aja@, jca@ no problem reports after being in snaps ok mpi@ Factor out TEXTREL mprotecting from the per-arch files into _dl_rtld(), 2019-08-06T04:01:41Z guenther guenther@openbsd.org 2019-08-06T04:01:41Z urn:sha1:90273bfb6a9670b47465d315bcdd9bfb5678fb5a hiding the actual grotty bits in inline functions ok mpi@ Simplify _dl_find_symbol(). Currently, it returns three values: 2019-08-04T23:51:45Z guenther guenther@openbsd.org 2019-08-04T23:51:45Z urn:sha1:143e5accc158c0698519f1aed096f85b567edde3 - the symbol it found, returned via the second argument - the base offset of the the object it was found in, via the return value - optionally: the object it was found in, returned via the last argument Instead, return a struct with the symbol and object pointers and let the caller get the base offset from the object's obj_base member. On at least aarch64, amd64, mips64, powerpc, and sparc64, a two word struct like this is passed in registers. ok mpi@, kettenis@ In 2004, we upgraded to binutils 2.14 with did -zcombreloc by default. 2019-07-21T03:54:16Z guenther guenther@openbsd.org 2019-07-21T03:54:16Z urn:sha1:518321a888a192cda6e8b9a18a281330aa108186 In 2013, I implemented the single-entry LRU cache that gets the maximal symbol reuse from combreloc. Since then, the ld.so generic relocation symcache has been a waste of CPU and memory with 0% hit-rate, so kill it. ok mpi@ make gc workaround compile on non-clang 2019-06-07T16:27:47Z deraadt deraadt@openbsd.org 2019-06-07T16:27:47Z urn:sha1:9dfb6b44065ea59fd096ceb2d2b264225c8b0f3b Disable the unmapping of ld.so's boot data for now, as boehm-gc apparently 2019-06-04T02:35:40Z guenther guenther@openbsd.org 2019-06-04T02:35:40Z urn:sha1:549b7b6109afe60173766758680f910680636285 follows some pointer into the middle of it. Best to keep things working while tracking down the wonkiness. problem noted by naddy@