Closures on powerpc64-linux using static trampolines do not work when
statically linking libffi. The problem is the usage of tramp_globals.text
in libffi assumes it contains the entry point address of the first trampoline.
Powerpc's ffi_tramp_arch code returns &trampoline_code_table which for ABIs
that use function descriptors, ends up returning trampoline_code_table's
function descriptor address instead of its entry point address. Update
the code to always return the entry point address for all ABIs.
Similarly to f515eac04cf8e5f594d5d9dee5fb7dfc3a186a4c, add a .note.GNU-stack
marker to pa/linux.S as it doesn't need an executable stack. Absence of the
note means that GNU Binutils will consider it as needing an executable stack
and mark it as such automatically.
When building libffi on HPPA with `-Wl,--warn-warn-execstack`, we get:
```
ld: warning: src/pa/.libs/linux.o: missing .note.GNU-stack section implies executable stack
ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker
```
That becomes more problematic with glibc-2.41 which forbids dlopen()
of a library with an executable stack, and libffi is commonly dlopen()'d,
especially by Python.
I suspect the reason it didn't show up on Debian is that since February,
Debian has been building Binutils with --disable-default-execstack.
Bug: https://bugs.gentoo.org/953805
Bug: https://github.com/libffi/libffi/issues/898
Add static trampoline support to all three powerpc Linux ABIs, specifically
powerpc-linux (32-bit SYSV BE), powerpc64-linux (64-bit ELFv1 BE) and
powerpc64le-linux (64-bit ELFv2 LE). This follows the s390x implementation
and does not introduce a ffi_closure_*_alt function, but rather jumps
directly to the ffi_closure_* function itself. If compiling with
--with-gcc-arch=power10 and pc-relative is enabled, we use a simpler and
smaller trampoline that utilizes Power10's new pc-relative load instructions.
I accidentally omitted the "ABI_ATTR" attribute, so that the testsuite
fails when testing the Microsoft ABI.
Fixes: fe203ffbb2bd ("Fix bugs in the x86-64 and x32 target (#887) (#889)")
Signed-off-by: Mikulas Patocka <mikulas@twibright.com>
This commit fixes two bugs in ffi in the x86-64 target. The bugs were
introduced by the commit d21881f55ed4a44d464c9091871e69b0bb47611a ("Fix
x86/ffi64 calls with 6 gp and some sse registers").
The first bug is that when we pass an argument with less than 8 bytes,
ffi will read memory beyond argument end, causing a crash if the argument
is located just before the end of the mapped region.
The second bug is in the x32 ABI - pointers in x32 are 4-byte, but GCC
assumes that the pointer values in the registers are zero-extended. ffi
doesn't respect this assumption, causing crashes in the called library.
For example, when we compile this function for x32:
int fn(int *a)
{
if (a)
return *a;
return -1;
}
we get this code:
fn:
testq %rdi, %rdi
je .L3
movl (%edi), %eax
ret
.L3:
movl $-1, %eax
ret
When we call this function using ffi with the argument NULL, the function
crashes because top 4 bytes of the RDI register are not cleared.
Fixes: d21881f55ed4 ("Fix x86/ffi64 calls with 6 gp and some sse registers (#848)")
Signed-off-by: Mikulas Patocka <mikulas@twibright.com>
While PAC was enabled, the bit to indicate support in the GNU Notes
section of the ELF was missing.
Before:
readelf -n ./aarch64-unknown-linux-gnu/.libs/libffi.so
Displaying notes found in: .note.gnu.property
Owner Data size Description
GNU 0x00000010 NT_GNU_PROPERTY_TYPE_0
Properties: AArch64 feature: BTI
This was caused by this file not having PAC indicated in GNU Notes and
the linker discarding it:
File: ./aarch64-unknown-linux-gnu/src/aarch64/sysv.o
Displaying notes found in: .note.gnu.property
Owner Data size Description
GNU 0x00000010 NT_GNU_PROPERTY_TYPE_0
Properties: AArch64 feature: BTI
Now it has it:
File: ./aarch64-unknown-linux-gnu/src/aarch64/sysv.o
Displaying notes found in: .note.gnu.property
Owner Data size Description
GNU 0x00000010 NT_GNU_PROPERTY_TYPE_0
Properties: AArch64 feature: BTI, PAC
As well as the output shared object:
readelf -n ./aarch64-unknown-linux-gnu/.libs/libffi.so
Displaying notes found in: .note.gnu.property
Owner Data size Description
GNU 0x00000010 NT_GNU_PROPERTY_TYPE_0
Properties: AArch64 feature: BTI, PAC
Fixes: #881
Signed-off-by: Bill Roberts <bill.roberts@arm.com>
* Emscripten: cleanup
* Emscripten: remove support for `-sWASM_BIGINT=0`
* Emscripten: remove redundant CircleCI config
* Emscripten: modernize CI
* Ensure test helper methods are static
Similar to #644.
* Fix test failures in `cls_multi_{s,u}shortchar`
To build ELF shared libraries that do not require executable stack on
MIPS, every object file linked should have a .note.GNU-stack section,
otherwise the linker defaults to executable stack.
As libffi shouldn't require executable stack, add the .note.GNU-stack
section to the assembly source files under src/mips, like other
architectures.
Signed-off-by: Icenowy Zheng <uwu@icenowy.me>
In the C23 revision of the C standard, `va_start` ignores its second
argument, which is no longer required (previously the last named
function parameter - which the compiler knows anyway, so it's
redundant information).
This has the consequence for the libffi testsuite, when making GCC
default to `-std=gnu23`, of making two tests fail with warnings about
an unused function argument (only passed to `va_start` and not
otherwise used). Fix those test failures by explicitly casting the
argument to `void`.
This is a fix for https://github.com/libffi/libffi/issues/852: error: invalid CFI advance_loc expression on apple targets.
The CFI for darwin arm64 was broken because the CNAME macro was being used after the
cfi_startproc macro.
The pattern for several of the architectures is for ffi_call_int to
stack-allocate some arguments + the registers, and then
ffi_call_$ARCH will pop the top of that structure into registers, and
then adjust the stack pointer such that the alloca'd buffer _becomes_
the stack-passed arguments for the function being called.
If libffi is compiled with ASAN, then there will be a redzone inserted
after the alloca'd buffer which is marked as poisoned. This redzone
appears beyond the end of $sp upon entry to the called function.
If the called function does anything to use this stack memory, ASAN will
notice that it's poisoned and report an error.
This commit fixes the situation (on the architectures that I have access
to) disabling instrumentation for ffi_call_int; that means there will be
no alloca redzone left on the shadow-stack.
* arc: Fix warnings
These warnings are fixed:
1. A series of "unused variables".
2. Implicit conversion from a pointer to uint32_t.
Signed-off-by: Yuriy Kolerov <ykolerov@synopsys.com>
* arc: Do not use mov_s and movl_s instructions
mov_s and movl_s instructions use a restricted set of registers.
However, a list of available registers for such instructions for
one ARC target may not match a list for another ARC targets. For
example, it is applicable to ARC700 and ARC HS3x/4x - build
fails because mov_s formats may be incompatible in some cases.
The easiest and the most straightforward way to fix this issue
is to use mov and movl instead of mov_s and movl_s.
Signed-off-by: Yuriy Kolerov <ykolerov@synopsys.com>
---------
Signed-off-by: Yuriy Kolerov <ykolerov@synopsys.com>
GNU tools are often installed with g-prefix on Solaris. Unfortunately, a check
in configure was using grep directly instead of through a variable, which lead
to wrong results due to missing option `-q`. Additionally, the check will fail
silently if `readelf` is not on `PATH` instead of trying `greadelf`.
* src/or1k/ffi.c: fix prototype of ffi_call_SYSV()
The current code base of libffi on OpenRISC (or1k) fails to build with
GCC 14.x with the following error:
../src/or1k/ffi.c: In function 'ffi_call':
../src/or1k/ffi.c:167:34: error: passing argument 3 of 'ffi_call_SYSV' from incompatible pointer type [-Wincompatible-pointer-types]
167 | ffi_call_SYSV(size, &ecif, ffi_prep_args, rvalue, fn, cif->flags);
| ^~~~~~~~~~~~~
| |
| void * (*)(char *, extended_cif *)
../src/or1k/ffi.c:113:27: note: expected 'void * (*)(int *, extended_cif *)' but argument is of type 'void * (*)(char *, extended_cif *)'
113 | void *(*)(int *, extended_cif *),
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This is due to the fact that ffi_prep_args() is in fact defined as:
void* ffi_prep_args(char *stack, extended_cif *ecif)
so, let's fix the prototype of the function pointer, which anyway gets
passed to assembly code, so the typing gets lost.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
* src/or1k/ffi.c: fix incompatible pointer type
The current code base of libffi on OpenRISC (or1k) fails to build with
GCC 14.x with the following error:
../src/or1k/ffi.c: In function 'ffi_closure_SYSV':
../src/or1k/ffi.c:183:22: error: initialization of 'char *' from incompatible pointer type 'int *' [-Wincompatible-pointer-types]
183 | char *stack_args = sp;
| ^~
Indeed:
register int *sp __asm__ ("r17");
[..]
char *stack_args = sp;
Adopt the same logic used for:
char *ptr = (char *) register_args;
which consists in casting to the desired pointer type. Indeed, later
in the code stack_args is assigned to ptr (so they need to be the same
pointer type), and some arithmetic is done on ptr, so changing its
pointer type would change the behavior.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
---------
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
This is needed at least if building for Linux, with a toolchain
that doesn't default to having PAC enabled, fixing build errors
since 45d284f2d066cc3a080c5be88e51b4d934349797.
* aarch64: fix callstack in ffi_call_SYSV
The debug stack gets corrupted between the frame and stack pivots, update
the CFI directives so the call stack stays correct in the debugger.
str x9, [x1, #32] // stack is ffi_call_SYSV() -> ffi_call_int() -> ffi_call_int() -> main() (good)
mov x29, x1 // stack is ffi_call_SYSV() -> ffi_call_int() -> ffi_call_int() -> ffi_call() -> main() (bad)
mov sp, x0 // stack is ffi_call_SYSV() -> ffi_call_int() -> ffi_call_int() -> main() (good)
The CFA data needs to be updated around the pivots, after this patch the
callstack stays correct.
Signed-off-by: Bill Roberts <bill.roberts@arm.com>
* aarch64: remove uneeded CFI directive
This directive doesn't actually set the CFA to anything valid, and
during unwinding this isn't even used. Note that the PAC/Darwin usage
is quite suspect as well, as the CFA is either x1 or x29 after the frame
pivot, and the CFA address is what's used as the modifier when verifying
the PAC. At least this is the behavior on Linux with PAC, I need to
verify ARME ABI unwinding. So for now leave Darwin as is.
Signed-off-by: Bill Roberts <bill.roberts@arm.com>
* ptrauth: rename define for clarity
Rename the HAVE_PTRAUTH define for clarity that its associated with the
ARM64E ABI and not the ARM64 ABI that can be supported on Linux and
enabled with -mbranch-protection=standard.
Signed-off-by: Bill Roberts <bill.roberts@arm.com>
* aarch64: add PAC support to ffi_call_SYSV
Support AARCH64 Pointer Authentication Codes (PAC) within ffi_call_SYSV
and support exception unwinding.
The Linux ABI for PAC is to use paciasp/autiasp instructions which also
have hint space equivelent instructions. They sign the LR (x30) with the
A key and the current stack pointer as the salt. Note that this can also be
configured to use the B key and will use pacibsp/autibsp hint instructions.
The Linux ABI for exception frame data when PAC is enabled assumes that the
Connonical Frame Address, or CFA is equal to the stack pointer. I.E sp is
equal to x29 (fp). When the unwinder is invoked the cfa will point to
the frame which will include the *signed* return address from the LR.
This will then be passed to __builtin_aarch64_autia1716 where the CFA
will be used as the salt and stored to register x16 and register x17
will contain the signed address to demangle. This can be noted in:
- d6d7afcdbc/libgcc/config/aarch64/aarch64-unwind.h (L56)
The other required portion of this is to indicate to the unwinder that
this is a signed address that needs to go the special demangle route in
the unwinder. This is accomplished by using CFI directive "cfi_window_save"
which marks that frame as being signed.
Putting all of this together is a bit tricky, as the internals of
ffi_call_SYSV the callee allocates its stack and frame and passes it in
arg1 (x0) and arg2 (x1) to the called function, where that function
pivots its stack, so care must be taken to get the sp == fp before
paciasp is called and also restore that state before autiasp is called.
Signed-off-by: Bill Roberts <bill.roberts@arm.com>
---------
Signed-off-by: Bill Roberts <bill.roberts@arm.com>
* bti: add identifier to ffi_closure_SYSV_V_alt
This was missing BTI_C identifier.
Old Code:
ffi_closure_SYSV_V_alt:
0000fffff7f70500: ldr x17, [sp, #8]
Signed-off-by: Bill Roberts <bill.roberts@arm.com>
* testsuite: fix whitespace in Makefile.am
Signed-off-by: Bill Roberts <bill.roberts@arm.com>
* aarch64: correct comment describing BTI
The comment is incorrect, BTI is enabled per mapping via mprotect with
PROT_BTI flag set, not per-process. When the loader loads the library,
if the GNU Notes section is missing this, PROT_BTI will not be enabled
for that mapping, but is independent of other mappings.
Signed-off-by: Bill Roberts <bill.roberts@arm.com>
---------
Signed-off-by: Bill Roberts <bill.roberts@arm.com>
