[v2,1/1] openssl: aarch64: configure with no-asm

From: Max Krummenacher <max.krummenacher@toradex.com>

openssl has a couple of functionalities which use optimized
assembler code. With no-asm these are replaced by generic
C code implementation.

With GCC 15 OE by default uses the new AARCH64 specific GCS feature.
However the object files produced by the assembler are not marked
to provide the feature and consequently the produced shared objects
containing them also not.
The linker will warn when linking against such shared objects files
and, with all warnings are errors set linking will fail.
Without this patch systemd e.g. fails do_compile as it links against
libcrypto.so from openssl.

To test what features an object file (or .so, .a file) has use
readelf -ln and check the content of .note.gnu.property, e.g.
libcrypto-shlib-md5-aarch64.o build from assembler source,
libcrypto-shlib-md5_one.o build from C source:

$ aarch64-poky-linux-readelf -ln ./crypto/md5/libcrypto-shlib-md5-aarch64.o

There are no program headers in this file.

Displaying notes found in: .note.gnu.property
  Owner                Data size        Description
  GNU                  0x00000010       NT_GNU_PROPERTY_TYPE_0
      Properties: AArch64 feature: BTI, PAC

$ aarch64-poky-linux-readelf -ln ./crypto/md5/libcrypto-shlib-md5_one.o

There are no program headers in this file.

Displaying notes found in: .note.gnu.property
  Owner                Data size        Description
  GNU                  0x00000010       NT_GNU_PROPERTY_TYPE_0
      Properties: AArch64 feature: BTI, PAC, GCS

Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
---
 meta/recipes-connectivity/openssl/openssl_3.5.0.bb | 2 ++
 1 file changed, 2 insertions(+)

For reference also refer to this thread:
https://lore.kernel.org/all/aBilFkr4HF-MSBd6@toolbox/

On Tue, May 6, 2025 at 7:11 AM Max Krummenacher via
lists.openembedded.org <max.oss.09=gmail.com@lists.openembedded.org>
wrote:
>
> From: Max Krummenacher <max.krummenacher@toradex.com>
>
> openssl has a couple of functionalities which use optimized
> assembler code. With no-asm these are replaced by generic
> C code implementation.
>
> With GCC 15 OE by default uses the new AARCH64 specific GCS feature.
> However the object files produced by the assembler are not marked
> to provide the feature and consequently the produced shared objects
> containing them also not.
> The linker will warn when linking against such shared objects files
> and, with all warnings are errors set linking will fail.
> Without this patch systemd e.g. fails do_compile as it links against
> libcrypto.so from openssl.
>
> To test what features an object file (or .so, .a file) has use
> readelf -ln and check the content of .note.gnu.property, e.g.
> libcrypto-shlib-md5-aarch64.o build from assembler source,
> libcrypto-shlib-md5_one.o build from C source:
>
> $ aarch64-poky-linux-readelf -ln ./crypto/md5/libcrypto-shlib-md5-aarch64.o
>
> There are no program headers in this file.
>
> Displaying notes found in: .note.gnu.property
>   Owner                Data size        Description
>   GNU                  0x00000010       NT_GNU_PROPERTY_TYPE_0
>       Properties: AArch64 feature: BTI, PAC
>
> $ aarch64-poky-linux-readelf -ln ./crypto/md5/libcrypto-shlib-md5_one.o
>
> There are no program headers in this file.
>
> Displaying notes found in: .note.gnu.property
>   Owner                Data size        Description
>   GNU                  0x00000010       NT_GNU_PROPERTY_TYPE_0
>       Properties: AArch64 feature: BTI, PAC, GCS

Good find. I was suspecting something like that, what happens if we
use compiler driver to invoke as assembler ?
another way might be to add CFI directives in asm files, maybe just
start and end
foo:
.cfi_startproc
...
 .cfi_endproc


>
> Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
> ---
>  meta/recipes-connectivity/openssl/openssl_3.5.0.bb | 2 ++
>  1 file changed, 2 insertions(+)
>
> For reference also refer to this thread:
> https://lore.kernel.org/all/aBilFkr4HF-MSBd6@toolbox/
>
> diff --git a/meta/recipes-connectivity/openssl/openssl_3.5.0.bb b/meta/recipes-connectivity/openssl/openssl_3.5.0.bb
> index 865e04deb220..d025fc3ff100 100644
> --- a/meta/recipes-connectivity/openssl/openssl_3.5.0.bb
> +++ b/meta/recipes-connectivity/openssl/openssl_3.5.0.bb
> @@ -36,6 +36,8 @@ B = "${WORKDIR}/build"
>  do_configure[cleandirs] = "${B}"
>
>  EXTRA_OECONF = "${@bb.utils.contains('PTEST_ENABLED', '1', '', 'no-tests', d)}"
> +# aarch64 'as' doesn't mark objects to have the GCS feature, resulting *.so then produces linker warnings
> +EXTRA_OECONF:append:aarch64 = " no-asm"

Does this disable assembly ? if so there might be a performance
impact, it would be good to find that out.

>
>  #| ./libcrypto.so: undefined reference to `getcontext'
>  #| ./libcrypto.so: undefined reference to `setcontext'
> --
> 2.42.0
>
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#216050): https://lists.openembedded.org/g/openembedded-core/message/216050
> Mute This Topic: https://lists.openembedded.org/mt/112649627/1997914
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [raj.khem@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>

Hi,

On Tue, May 06, 2025 at 07:21:09AM -0700, Khem Raj via lists.openembedded.org wrote:
> On Tue, May 6, 2025 at 7:11 AM Max Krummenacher via
> lists.openembedded.org <max.oss.09=gmail.com@lists.openembedded.org>
> wrote:
> >
> > From: Max Krummenacher <max.krummenacher@toradex.com>
> >
> > openssl has a couple of functionalities which use optimized
> > assembler code. With no-asm these are replaced by generic
> > C code implementation.
> >
> > With GCC 15 OE by default uses the new AARCH64 specific GCS feature.
> > However the object files produced by the assembler are not marked
> > to provide the feature and consequently the produced shared objects
> > containing them also not.
> > The linker will warn when linking against such shared objects files
> > and, with all warnings are errors set linking will fail.
> > Without this patch systemd e.g. fails do_compile as it links against
> > libcrypto.so from openssl.
> >
> > To test what features an object file (or .so, .a file) has use
> > readelf -ln and check the content of .note.gnu.property, e.g.
> > libcrypto-shlib-md5-aarch64.o build from assembler source,
> > libcrypto-shlib-md5_one.o build from C source:
> >
> > $ aarch64-poky-linux-readelf -ln ./crypto/md5/libcrypto-shlib-md5-aarch64.o
> >
> > There are no program headers in this file.
> >
> > Displaying notes found in: .note.gnu.property
> >   Owner                Data size        Description
> >   GNU                  0x00000010       NT_GNU_PROPERTY_TYPE_0
> >       Properties: AArch64 feature: BTI, PAC
> >
> > $ aarch64-poky-linux-readelf -ln ./crypto/md5/libcrypto-shlib-md5_one.o
> >
> > There are no program headers in this file.
> >
> > Displaying notes found in: .note.gnu.property
> >   Owner                Data size        Description
> >   GNU                  0x00000010       NT_GNU_PROPERTY_TYPE_0
> >       Properties: AArch64 feature: BTI, PAC, GCS
> 
> Good find. I was suspecting something like that, what happens if we
> use compiler driver to invoke as assembler ?
> another way might be to add CFI directives in asm files, maybe just
> start and end
> foo:
> .cfi_startproc
> ...
>  .cfi_endproc

This may be needed in a lot of places...
 
> >
> > Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
> > ---
> >  meta/recipes-connectivity/openssl/openssl_3.5.0.bb | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > For reference also refer to this thread:
> > https://lore.kernel.org/all/aBilFkr4HF-MSBd6@toolbox/
> >
> > diff --git a/meta/recipes-connectivity/openssl/openssl_3.5.0.bb b/meta/recipes-connectivity/openssl/openssl_3.5.0.bb
> > index 865e04deb220..d025fc3ff100 100644
> > --- a/meta/recipes-connectivity/openssl/openssl_3.5.0.bb
> > +++ b/meta/recipes-connectivity/openssl/openssl_3.5.0.bb
> > @@ -36,6 +36,8 @@ B = "${WORKDIR}/build"
> >  do_configure[cleandirs] = "${B}"
> >
> >  EXTRA_OECONF = "${@bb.utils.contains('PTEST_ENABLED', '1', '', 'no-tests', d)}"
> > +# aarch64 'as' doesn't mark objects to have the GCS feature, resulting *.so then produces linker warnings
> > +EXTRA_OECONF:append:aarch64 = " no-asm"
> 
> Does this disable assembly ? if so there might be a performance
> impact, it would be good to find that out.

Or security win? What does upstream recommend?

This GCS is now enabled with -mbranch-protection=standard. There may be more places
which need similar fixes/workarounds so getting this working automatically
would be better. Bug report to gcc?

I wonder if GCS should be disabled for now and use "bti" instead?

https://gcc.gnu.org/onlinedocs/gcc-15.1.0/gcc/AArch64-Options.html#index-mbranch-protection

Cheers,

-Mikko

On 6 May 2025, at 15:10, Max Krummenacher via lists.openembedded.org <max.oss.09=gmail.com@lists.openembedded.org> wrote:
> $ aarch64-poky-linux-readelf -ln ./crypto/md5/libcrypto-shlib-md5-aarch64.o
> 
> There are no program headers in this file.
> 
> Displaying notes found in: .note.gnu.property
>  Owner                Data size        Description
>  GNU                  0x00000010       NT_GNU_PROPERTY_TYPE_0
>      Properties: AArch64 feature: BTI, PAC
> 
> $ aarch64-poky-linux-readelf -ln ./crypto/md5/libcrypto-shlib-md5_one.o
> 
> There are no program headers in this file.
> 
> Displaying notes found in: .note.gnu.property
>  Owner                Data size        Description
>  GNU                  0x00000010       NT_GNU_PROPERTY_TYPE_0
>      Properties: AArch64 feature: BTI, PAC, GCS

Some context here: openssl has some assembler code that has PAC and BTI hints but not GCS. The systemd recipe then links to libcrypto from openssl with GCS enabled (as that is a distro-wide setting) and it - correctly - warns that it’s being told to use GCS but one of the inputs doesn’t have GCS.  This wouldn’t be a problem but systemd also links with —fatal-warnings, so the build explodes.

I’m asking people internally who know more about this than me, but it’s possible that the proper fix here is to just add the GCS tag. Alternatively, relaxing the systemd build so that it doesn’t have fatal warnings (or consider GCS issues a warning) would be a fallback.  Disabling the assembler fast-paths because of this is an incredibly blunt hammer.

Ross