Index | Thread | Search

From:
Stuart Henderson <stu@spacehopper.org>
Subject:
Re: devel/ruby-ffi failure on arm64 BTI
To:
Klemens Nanni <kn@openbsd.org>
Cc:
ports <ports@openbsd.org>, Jeremy Evans <jeremy@openbsd.org>
Date:
Mon, 23 Mar 2026 20:14:33 +0000

Download raw body.

Thread
On 2026/03/23 19:39, Klemens Nanni wrote:
> 22.03.2026 22:23, Stuart Henderson пишет:
> > On 2026/03/22 15:51, Klemens Nanni wrote:
> >> 	# pkg_add ruby34-ffi
> >> 	$ ktrace -di ruby34 /usr/local/lib/ruby/gems/3.4/gems/ffi-1.17.2/samples/getpid.rb
> >> 	[ big dump of loaded files ]
> >> 	Illegal instruction (core dumped)
> >>
> >> 	$ kdump | grep BTCFI
> >> 	 88448 ruby34   PSIG  SIGILL caught handler=0x221c893fcc mask=0<> code=ILL_BTCFI addr=0x22b6114000 trapno=905969665
> > ...
> >> Even with USE_NOBTCFI-aarch64=Yes in lang/ruby/3.4 (as well as devel/ruby-ffi
> >> and devel/libffi for good measure) it still fails.
> > 
> > does it make it into the binary? objdump -p | grep OPENBSD
> > (compare with e.g. python3).
> 
> No, but now it does and Ruby no longer dies, getpid.rb and openfact work!
> 
> OPENBSD_NOBTCFI off    0x0000000000000000 vaddr 0x0000000000000000 paddr 0x0000000000000000 align 2**0
> 
> Remains to see why Ruby is special while ffi-getpid.c works fine with BTI/PAC.
> 
> 
> 
> So I only checked like this:
> 
> 	$ make show=USE_NOBTCFI       
> 	Yes     
> 
> But this is where it fails already:
> 
> 	$ make show=_LINKER_FLAGS 
> 	 -z wxneeded
> 
> Going over bsd.port.mk code, it really baffled me, until double checked
> my Makefile changes:
> 
> 	$ head -n1 Makefile
> 	USE_NOBTCFI-aarch64 =   Yes     # devel/libffi
> 	$ make show=USE_NOBTCFI-aarch64
> 	Yes     
> 	$ make show=USE_NOBTCFI-aarch64 | hexdump -C
> 	00000000  59 65 73 09 0a                                    |Yes..|
> 	00000005
> 
> That delimiting tab is consumed into the variable's value, hence why
> make's ${USE_NOBTCFI:L} == "yes" never matched...
> 
> We do this all over at least for SHARED_LIBS, but apparently these
> variables/values are handled in a way that doesn't have this problem.
> 

ha yes. that is a common gotcha for yes/no variables. it's possible to
have a looser match with :L:Myes, but I worry that it might be a bit too
loose sometimes then..
(