Index | Thread | Search

From:
Mark Kettenis <mark.kettenis@xs4all.nl>
Subject:
Re: missing endbr64
To:
Stuart Henderson <stu@spacehopper.org>
Cc:
tb@theobuehler.org, ports@openbsd.org
Date:
Sun, 25 Feb 2024 20:31:48 +0100

Download raw body.

Thread
> Date: Sun, 25 Feb 2024 18:43:54 +0000
> From: Stuart Henderson <stu@spacehopper.org>
> 
> > > sysutils/borgbackup/2.0.log: lots of warnings about symbols from openssl/3.1:
> > > ld: warning: aesni_set_decrypt_key: missing endbr64
> > > ld: warning: aesni_set_encrypt_key: missing endbr64
> > > ld: warning: ChaCha20_ctr32: missing endbr64
> > > ld: warning: bn_mul_mont: missing endbr64
> > > ld: warning: bn_mul_mont_gather5: missing endbr64
> > > ld: warning: bn_power5: missing endbr64
> > > ld: warning: bn_get_bits5: missing endbr64
> > > ld: warning: bn_scatter5: missing endbr64
> > > ld: warning: bn_gather5: missing endbr64
> > > ld: warning: rsaz_1024_sqr_avx2: missing endbr64
> > > ld: warning: rsaz_1024_mul_avx2: missing endbr64
> > > etc
> > 
> > WTF, so this links against the static version of the lib in order to
> > be able to call non-public functions?  USE_NOBTCFI and laugh at them?
> 
> Links against the static version to try and avoid symbol conflicts
> with libressl libs (which python is linked against).

Ah, Python.  So it is building a Python module with the crypto in it
and because you're linking in it is re-exporting the internal openssl
symbols.  But Python uses NOBTCFI so this is not an immediate problem.