link_elf: Make phdrs first page check actually fatal
Otherwise we'll print an error but carry on regardless, presumably
destined to walk off the end of the mapping.
Reported by: thebugfixers at pm.me
MFC after: 1 week
(cherry picked from commit 1e39a314d870e312f623199e146eda6bdbc293a3)
Merge commit 6b0a46958c56 from llvm-project (by Piotr Kubaj):
[libunwind][PPC64] Fix unw_getcontext corrupting callee-saved VSX registers on LE (#198371)
This is the first of two independent fixes for libunwind on ppc64le
(ELFv2 ABI, little-endian), where two separate bugs together cause
SIGSEGV during backtracing. This commit addresses the VSX register
corruption; the TOC-restore fault is handled in a follow-up. Both
were discovered while debugging lang/rust build failures with
RUST_BACKTRACE=1 on FreeBSD/powerpc64le (IBM POWER9).
On ppc64le, `unw_getcontext` saves each VS register with an in-place
`xxswapd n, n` followed by `stxvd2x`. The swap is needed because
`stxvd2x` stores doublewords in the wrong order on LE. However, the
macro never applies a second `xxswapd` to restore the register after
the store, so all 64 VS registers are permanently corrupted on return
from `unw_getcontext`.
This affects every callee-saved VSX register: f14-f31 (VSR14-VSR31)
[13 lines not shown]
Merge commit 26bf39cdba0b from llvm-project (by Jessica Clarke):
[ELF][PowerPC] Don't assume TOC pointer is valid in IPLT entries (#207555)
Unlike normal PLT entries, IPLT entries can be called indirectly even
when in PIEs/DSOs, and so there's no guarantee on what's in the TOC
pointer register at that time. Therefore we must emit variants of the
existing code that work without it, whether r12-relative (playing the
same role as MIPS's $25) in the same number of instructions, or first
retrieving PC in an i386-like manner, being careful not to clobber LR.
On 32-bit PowerPC even direct calls to IPLT entries face the same issue,
since we'd use the TOC base of the resolver, which may not be the same
as the caller, even within the same object.
Normal canonical PLTs still look broken on 64-bit PowerPC as they use
the TOC pointer register too, and similarly on 32-bit PowerPC for PIEs.
We should probably treat these cases the same as PIE on i386 (except
including PDEs for 64-bit PowerPC), where it's an error due to the use
of %ebx in PLT entries.
[9 lines not shown]
Merge commit cbf48349e3e1 from llvm-project (by Jessica Clarke):
[NFC][ELF][PPC64] Pass address not offset to writePPC64LoadAndBranch (#212275)
Every caller currently subtracts the TOC base in its argument, so move
that into common code inside writePPC64LoadAndBranch. This will also
allow a different computation to be used in some cases in a future
commit.
Note that offset is now unsigned not signed; even previously, all
arguments were uint64_t, and all uses are unsigned, so making it signed
doesn't make much sense.
MFC after: 1 week
(cherry picked from commit bcbcd7303009344dc1051e4601284620bca29be8)
libllvmminimal: Fix building with LLVM < 21 on riscv64
On most architectures we end up not needing ABIBreak.cpp as, although
some of the sources here do reference EnableABIBreakingChecks (or, if
assertions are disabled, DisableABIBreakingChecks) at a source level, we
compile with -ffunction-sections and -fdata-sections, and link with
--gc-sections, and it happens to be the case that all references can be
GC'ed. However, prior to LLVM 21, the RISC-V backend did not apply
-fdata-sections to .sdata, where references to these symbols end up, and
for some files we're building with such references we end up not being
able to GC .sdata due to the other unrelated data in it, meaning that we
do in fact need to build ABIBreak.cpp.
Whilst we could make this conditional on the architecture, it's a tiny
file, and it's a bit fragile to rely on GC behaviour, so just include it
unconditionally.
Reviewed by: dim, emaste
Fixes: 770cf0a5f02d ("Fixups after llvm-project main llvmorg-21-init-19288-gface93e724f4 merge")
[4 lines not shown]
link_elf: Make phdrs first page check actually fatal
Otherwise we'll print an error but carry on regardless, presumably
destined to walk off the end of the mapping.
Reported by: thebugfixers at pm.me
MFC after: 1 week
(cherry picked from commit 1e39a314d870e312f623199e146eda6bdbc293a3)
Merge commit 6b0a46958c56 from llvm-project (by Piotr Kubaj):
[libunwind][PPC64] Fix unw_getcontext corrupting callee-saved VSX registers on LE (#198371)
This is the first of two independent fixes for libunwind on ppc64le
(ELFv2 ABI, little-endian), where two separate bugs together cause
SIGSEGV during backtracing. This commit addresses the VSX register
corruption; the TOC-restore fault is handled in a follow-up. Both
were discovered while debugging lang/rust build failures with
RUST_BACKTRACE=1 on FreeBSD/powerpc64le (IBM POWER9).
On ppc64le, `unw_getcontext` saves each VS register with an in-place
`xxswapd n, n` followed by `stxvd2x`. The swap is needed because
`stxvd2x` stores doublewords in the wrong order on LE. However, the
macro never applies a second `xxswapd` to restore the register after
the store, so all 64 VS registers are permanently corrupted on return
from `unw_getcontext`.
This affects every callee-saved VSX register: f14-f31 (VSR14-VSR31)
[13 lines not shown]
Merge commit 26bf39cdba0b from llvm-project (by Jessica Clarke):
[ELF][PowerPC] Don't assume TOC pointer is valid in IPLT entries (#207555)
Unlike normal PLT entries, IPLT entries can be called indirectly even
when in PIEs/DSOs, and so there's no guarantee on what's in the TOC
pointer register at that time. Therefore we must emit variants of the
existing code that work without it, whether r12-relative (playing the
same role as MIPS's $25) in the same number of instructions, or first
retrieving PC in an i386-like manner, being careful not to clobber LR.
On 32-bit PowerPC even direct calls to IPLT entries face the same issue,
since we'd use the TOC base of the resolver, which may not be the same
as the caller, even within the same object.
Normal canonical PLTs still look broken on 64-bit PowerPC as they use
the TOC pointer register too, and similarly on 32-bit PowerPC for PIEs.
We should probably treat these cases the same as PIE on i386 (except
including PDEs for 64-bit PowerPC), where it's an error due to the use
of %ebx in PLT entries.
[9 lines not shown]
arm64/vmm: Fix vgic_v3 dropping EOI for disabled IRQs
Now that IRQs can properly be disabled by GICD_ICENABLERn, an EOI for a
disabled IRQ ends up being lost, since we don't assign it to a list
register and don't enable maintenance interrupts for such cases. As a
result, we keep the IRQ active, which stops it from ever being delivered
again (which would be true even if we supported the active and pending
state). Keep disabled but active IRQs around in list registers so we can
see the EOI having taken place in a future sync (noting that since we
already don't create list registers in active and pending state there
are no concerns with causing a disabled IRQ to be delivered).
Fixes: 47e073941f4e ("Import the kernel parts of bhyve/arm64")
MFC after: 1 week
(cherry picked from commit 123dfd378959aecc97cfc1d9b457453194d6f25b)
libllvmminimal: Fix building with LLVM < 21 on riscv64
On most architectures we end up not needing ABIBreak.cpp as, although
some of the sources here do reference EnableABIBreakingChecks (or, if
assertions are disabled, DisableABIBreakingChecks) at a source level, we
compile with -ffunction-sections and -fdata-sections, and link with
--gc-sections, and it happens to be the case that all references can be
GC'ed. However, prior to LLVM 21, the RISC-V backend did not apply
-fdata-sections to .sdata, where references to these symbols end up, and
for some files we're building with such references we end up not being
able to GC .sdata due to the other unrelated data in it, meaning that we
do in fact need to build ABIBreak.cpp.
Whilst we could make this conditional on the architecture, it's a tiny
file, and it's a bit fragile to rely on GC behaviour, so just include it
unconditionally.
Reviewed by: dim, emaste
Fixes: 770cf0a5f02d ("Fixups after llvm-project main llvmorg-21-init-19288-gface93e724f4 merge")
[4 lines not shown]
Merge commit cbf48349e3e1 from llvm-project (by Jessica Clarke):
[NFC][ELF][PPC64] Pass address not offset to writePPC64LoadAndBranch (#212275)
Every caller currently subtracts the TOC base in its argument, so move
that into common code inside writePPC64LoadAndBranch. This will also
allow a different computation to be used in some cases in a future
commit.
Note that offset is now unsigned not signed; even previously, all
arguments were uint64_t, and all uses are unsigned, so making it signed
doesn't make much sense.
MFC after: 1 week
(cherry picked from commit bcbcd7303009344dc1051e4601284620bca29be8)
arm64/vmm: Fix vgic_v3 copy paste error for writing to GICD_ICENABLERn
Otherwise we try to disable the wrong IRQ.
Fixes: 47e073941f4e ("Import the kernel parts of bhyve/arm64")
MFC after: 1 week
(cherry picked from commit 422a530c80080f2585ecefe812d609079b851fe3)
vm: Remove a reference to an undefined memattr
This is a direct commit to stable/15.
Reported by: jenkins
Fixes: c4ea6b08e24e ("vm_phys: Add a sysctl to dump registered fictitious memory ranges")
net/if.c: Add fib-aware ifa_ifwithaddr()
Add FIB selection logic by introducing ifa_ifwithaddr_fib() to
support FIB-specific lookups. Then have ifa_ifwithaddr() wrap it
with RT_ALL_FIBS.
Also, do the same for ifa_ifwithaddr_check().
Reviewed by: glebius, bnovkov
Differential Revision: https://reviews.freebsd.org/D58305
(cherry picked from commit b00d30950cde27eda8f51523a40f2c05a38daac1)
bind(2): Lookup local address in current FIB if '*.bind_all_fibs' is active
When a protocol-specific 'bind_all_fibs' tunable is set to 0, a
listening socket will only receive traffic originating from the FIB
it was bound to. However, there are no checks to determine whether
an address exists in the target FIB when binding the socket, which can
lead to a situation where a socket and the address it was bound to
belong to different FIBs.
Prevent this footgun by looking up the requested address in the current
FIB if 'bind_all_fibs' is active and returning an error if the address
does not exist.
Sponsored by: Stormshield
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D58281
Reviewed by: glebius, pouria, markj
MFC after: 2 weeks
(cherry picked from commit 948ad32ae1e0811f45e1d38f26636fefed5051f0)
Revert "loopback: improve checksum offloading"
This reverts commit d6c4cea7740d5c5c673a06ba37e4f1bdcddb2ece.
It is done because this change interferes with the ipfilter
NAT functionality. So Back it out until ipfilter has been fixed.
kqueue: Add a helper macro for sleeping on in-flux knotes
Other in-flux operations are implemented by this set of macros, so we
should do the same for sleeping.
No functional change intended.
Reviewed by: kib
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D58443
(cherry picked from commit 1f4b0ea4f3eb1b8a885eff8bd0d332156f0c3e1f)
ppp: Avoid overflow when formatting endpoint discriminator options
Each byte of the address is represented by a pair of characters, so we
should be multiplying len by 2 when figuring out how much buffer space
we have. Previously, a sufficiently large option could cause an
overflow of the global "result" buffer.
Reported by: Joshua Rogers <joshua at joshua.hu>
Tested by: Décio Brandão (0xDBJ)
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D58555
(cherry picked from commit e004ff15f87e6aa8f2aa13cd5600ae13457b95f1)
kqueue: Associate marker knotes with a queue
Otherwise the assertion in KQ_FLUX_SLEEP_WMESG may fail.
kqueue_fork_copy() already handles this.
Fixes: 1f4b0ea4f3eb ("kqueue: Add a helper macro for sleeping on in-flux knotes")
Reported by: syzkaller
Reported by: kbowling
Reviewed by: kib
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D58516
(cherry picked from commit 9a9349ea1da2d80e979fa87b430551d8f6dac7f4)
ktls: Propagate EPG_FLAG_ANON to mapped mbufs
Otherwise ktls_mbuf_crypto_state() will reject mbufs created by
_mb_unmapped_to_ext(), which arises when transmitting packets through an
interface that doesn't support unmapped mbufs, and the loopback
interface in particular.
PR: 296498
Fixes: 3444414cb463 ("ktls: Don't attempt to modify non-anonymous mbufs on the receive path")
Reviewed by: gallatin, jhb
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D57557
(cherry picked from commit 815976ee14121bafe8a8ab002459d32f8928f2de)
vm: Make sure NULL is defined for vm_memattr_name()
Fixes: a7e483ee146a ("vm_phys: Add a sysctl to dump registered fictitious memory ranges")
(cherry picked from commit 11edc985cd9c2e1dcceccb7e929c6921b4e20c9b)
ipsec: Fix a lock leak in ipsec_chkreplay()
Reported by: Chris Jarrett-Davies of the OpenAI Codex Security Team
Reviewed by: pouria, kp
Fixes: 0361f165f219 ("ipsec: replace SECASVAR mtx by rmlock")
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D58521
(cherry picked from commit b6823a973737f06ea6cf0ea5a3083383af2ba5a4)
vm_phys: Add a sysctl to dump registered fictitious memory ranges
I've wanted this a couple of times in the past. Save the memattr in
the fictitious memory segment structure so that we can report it from
the sysctl handler, and add conversion routines for each platform.
Reviewed by: kib
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D58283
(cherry picked from commit a7e483ee146a93ac89357676fdb9af62ac58b4bc)
kqueue: Allocate marker knotes on the stack
The scan marker was originally stack-allocated. In commit
1c0f9af5b5224, it became heap-allocated since the marker is visible to
other threads and a scanning thread's stack may be swapped out. Now
that kernel stacks can no longer be swapped out, we can avoid these heap
allocations.
Reviewed by: kib
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D58402
(cherry picked from commit bb933b1d1846b3a984670b8cd65450c3333188f6)
