FreeBSD source tree https://cgit-dev.freebsd.org/src/atom?h=releng%2F14.4 2025-12-15T16:58:45Z 2025-12-15T16:58:45Z Jessica Clarke jrtc27@FreeBSD.org 2025-07-11T01:07:04Z urn:sha1:362eb7d340140ba02724e275d8d5ff2e2dcdaf90 This was copied from arm to aarch64 to riscv, but only arm uses it. MFC after: 1 week (cherry picked from commit 02d06043ba88f931f9debd5aa519fc303ca70d11) 2025-12-15T16:58:45Z Jessica Clarke jrtc27@FreeBSD.org 2025-05-28T20:24:52Z urn:sha1:02cb2f8094baab0b4299e5fcd1694d9193be14b3 This was applying a NetBSD fix to FreeBSD. However, the original code was correct for FreeBSD. NetBSD's obj->tlsoffset is relative to the end of the TCB, not the TCB itself, whilst ours is relative to the TCB[1] itself. For example, our allocate_tls uses (char *)tcb + obj->tlsoffset for the memcpy and memset calls. Without this reverted, for dynamically loaded shared objects, Initial Exec accesses to TLS variables on variant I architectures (non-x86) use the correct address, whilst General Dynamic and dlsym(3) use the incorrect address (TLS_TCB_SIZE past the start). Note that, on arm64, LLVM only supports TLSDESC (including LLD) and TLSDESC will use the static resolver if the variable ends up allocated to the static TLS block, even in the presence of dlopen(3), so only dlsym(3) shows the discrepancy there. Whilst here, add a comment to explain this difference to try and avoid the same mistake being made in future. [1] In the case of variant II, it's the amount to subtract, so still positive This reverts commit e9a38ed2fa61fd264a80f24ceb35f39b0ac6463d. Reviewed by: kib (prior version) Fixes: e9a38ed2fa61 ("rtld: fix allocate_module_tls() variant I fallback to static allocation") MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D50565 (cherry picked from commit ccfb1c50e45dbb7fcadf7e1932f63cf1702ef13a) 2025-12-15T16:58:45Z Jessica Clarke jrtc27@FreeBSD.org 2025-05-28T20:22:15Z urn:sha1:acf47e5d105ef05ea25b635672417a294a933e13 Provided you don't run out of extra static TLS space this should work, but it's wholly unnecessary and not how things are supposed to be done. Only static TLS relocations should allocate static TLS. Reviewed by: kib Fixes: 4b1859c0e943 ("Add support for RISC-V architecture.") MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D50563 (cherry picked from commit 03801d449a3731cb643a51625c8c4d5d07b2e54c) 2025-12-15T16:58:44Z Jessica Clarke jrtc27@FreeBSD.org 2025-05-06T22:14:51Z urn:sha1:8e8ae9ac48cc59615dd83d2b5fe1368036ff8808 For direct exec mode we reuse map_object, but tls_max_index is initialised to 1. As a result, the executable ends up being assigned module 2 (and the generation is pointlessly incremented, unlike in digest_phdr for the normal case). For most architectures this is harmless, since TLS linker relaxation will optimise General Dynamic accesses to Initial Exec or Local Exec for executables, but on RISC-V this relaxation does not exist, yet the linker will initialise the tls_index in the GOT with module 1, and at run time the call to __tls_get_addr will fail with: ld-elf.so.1: Can't find module with TLS index 1 Fix this by making map_object use 1 for obj->tlsindex when it's loading the main executable, and don't bother to increment tls_dtv_generation either, matching digest_phdr (though that one is harmless). (Note this also applies to MIPS on stable/13) Reviewed by: kib Fixes: 0fc65b0ab82c ("Make ld-elf.so.1 directly executable.") MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D50186 (cherry picked from commit a08d92def20a41243d4afc97cf4a2124be5386b9) 2025-12-15T16:58:44Z Jessica Clarke jrtc27@FreeBSD.org 2025-05-06T22:14:51Z urn:sha1:f1344d0aa816d0a2e9b316d4bd28b5f478b5d3da If no extra rtld arguments are provided, rtld_argc will be 1 (for argv[0] and so we are shifting the entire memory range down by a single pointer. However, unlike argv and envp, auxp's entries are two pointers in size, not one, and so in this case the source and destination overlap, meaning simple assignment is UB (C99 6.5.16.1p3). On many architectures this ends up being harmless as the compiler will emit double machine word loads and stores, or if it splits them it may still schedule them such that it works in this case, but our RISC-V baseline does not include such instructions and LLVM ends up picking a schedule that copies the second word before the first word, thereby replacing the first word with a copy of the second word. This results in direct exec mode segfaulting on RISC-V when given no arguments. Fix this by using a temporary in the source and let the compiler safely elide its use. Reviewed by: kib Fixes: 0fc65b0ab82c ("Make ld-elf.so.1 directly executable.") MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D50185 (cherry picked from commit 2b04ba6e08b983d8756552286846059507bca7a3) 2025-12-15T16:58:44Z Jessica Clarke jrtc27@FreeBSD.org 2025-05-06T22:14:51Z urn:sha1:79b0a953ada4c516c43f163c51d3f083da666d59 The implementation of dl_iterate_phdr abuses tls_get_addr_slow to get to the start of the TLS block, inlining the implementation of __tls_get_addr as if the tls_index's ti_offset were 0 (historically it called __tls_get_addr itself but changed due to locking issues). For most architectures, tls_index's ti_offset (relocated by DTPOFF/DTPREL for GOT entries) is just the offset within that module's TLS block. However, for PowerPC and RISC-V, which have a non-zero TLS_DTV_OFFSET and thus are designed assuming DTV entries are biased by that value, ti_offset normally has TLS_DTV_OFFSET pre-subtracted, but it's __tls_get_addr's responsibility to compensate for that. By using an offset of zero here, tls_get_addr_slow will return a pointer to the start of the TLS block itself, so by adding TLS_DTV_OFFSET we will point TLS_DTV_OFFSET past the module's TLS block. Fix this by removing the extra bias (the alternative would be to pass -TLS_DTV_OFFSET and keep the addition, which would more closely follow what __tls_get_addr does, but this is more direct). (Note this also applies to MIPS on stable/13) Reviewed by: kib Fixes: d36d68161517 ("rtld dl_iterate_phdr(): dlpi_tls_data is wrong") MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D50184 (cherry picked from commit c02aaba1b4549c1c3b1481f7c935f6cc80b98e8d) 2025-12-15T16:58:44Z Jessica Clarke jrtc27@FreeBSD.org 2025-05-06T22:14:51Z urn:sha1:e73457d194b000a53218a77564730e87b84f66af The implementation here is meant to mirror what a GOT entry for the given symbol would use for ti_offset. However, on PowerPC and RISC-V, TLS_DTV_OFFSET is non-zero, and so the GOT entries are normally biased by this, but we fail to do so here. As a result we end up getting a pointer TLS_DTV_OFFSET past where the variable actually is. (Note this also applies to MIPS on stable/13) Reviewed by: kib Fixes: 5ceeeba90c6c ("Import DragonFly BSD commit") MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D50183 (cherry picked from commit 8ad9cec3a2cc643020a286ee68f70eb01225fbdd) 2025-12-15T16:58:43Z Jessica Clarke jrtc27@FreeBSD.org 2024-08-22T19:36:44Z urn:sha1:f61eabc1f4cffaedb733262a8fd07f3011f6d827 GNU/Linux has historically had the following two resolver prototypes: 1. Elf_Addr(uint64_t, void *) 2. Elf_Addr(uint64_t, void *, void *) For the former, AT_HWCAP is passed in the first argument, and NULL in the second. For the latter, AT_HWCAP is still passed, and the second argument is a pointer to their home-grown __riscv_hwprobe function. Should they want to use the third argument in future, they'll have to introduce yet another prototype to allow for later expansion, and then all users will have to check whether the second argument is NULL to know if the third argument really exists. This is all rather silly and will surely prove fun in the face of type-checking CFI. Instead, be like arm64 and just define all 8 possible general purpose register arguments up front. To naive source code that forgets non-Linux OSes exist this will be compatible with prototype 1 above, since the second argument will be 0 and it won't look further (though should we start using the second argument for something that wouldn't be true any more and it might think it's __riscv_hwprobe, but that incompatibility is one we can defer committing to, and can choose to never adopt). Until the standard interface for querying extension information[1] is settled and implemented in FreeBSD there's not much you can do in a resolver other than use HWCAP_ISA_B, but this gets the infrastructure in place for when that day comes. [1] https://github.com/riscv-non-isa/riscv-c-api-doc/pull/74 Reviewed by: kib, mhorne MFC after: 1 month Differential Revision: https://reviews.freebsd.org/D46278 (cherry picked from commit 729d2b16b74fa5207a12aa1de190bd930432810e) 2025-12-15T16:58:43Z Jessica Clarke jrtc27@FreeBSD.org 2024-08-22T19:36:44Z urn:sha1:d5d8583a16ef533dfd8e1164401c4960417014ad Currently we pass the raw pointer to the on-stack auxargs. This can legitimately have fewer than AT_COUNT entries, so the use of __min_size(AT_COUNT), i.e. static AT_COUNT, is inaccurate, and also needlessly forces the callee to iterate over the elements to find the entry for a given type. Instead we can just pass aux_info like we use for everything else. Note that the argument has been left unused by every callee since its introduction in 4352999e0e6c ("Pass CPUID[1] %edx (cpu_feature), %ecx (cpu_feature2) and CPUID[7].%ebx (cpu_stdext_feature), %ecx (cpu_stdext_feature2) to the ifunc resolvers on x86.") Reviewed by: kib MFC after: 1 month Differential Revision: https://reviews.freebsd.org/D46276 (cherry picked from commit 33658afd4e4d11cd71d92e52ca9da5381cdd829b) 2025-12-05T10:58:57Z Dag-Erling Smørgrav des@FreeBSD.org 2025-12-03T10:09:31Z urn:sha1:307a6241d05ab8280a821767261b2ff194662b3b This prevents dumping the memory layout of setugid processes. MFC after: 3 days Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D54033 (cherry picked from commit 5242bcff202fa2a5a39895423c8d8c11c02ad76a)