Re: [OE-core][Patch v2 1/1] openssl: aarch64: configure with no-asm

[Mikko Rapeli <mikko.rapeli@linaro.org>]

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