[1/2] toolchain/external: copy libssp.so if SSP is enabled
diff mbox series

Message ID 20190902063728.31203-1-ydroneaud@opteya.com
State Superseded
Headers show
Series
  • [1/2] toolchain/external: copy libssp.so if SSP is enabled
Related show

Commit Message

Yann Droneaud Sept. 2, 2019, 6:37 a.m. UTC
Unlike libgcc_s.so, libssp.so is not copied on the target file
system. As it's available at link time, allowing packages such
as sox to be linked against the library.

As it's not copied, running programs linked against libssp.so
lead to failure such as the following:

  $ sox
  sox: error while loading shared libraries: libssp.so.0: cannot open shared object file: No such file or directory

  $ rec
  rec: error while loading shared libraries: libssp.so.0: cannot open shared object file: No such file or directory

If BR2_SSP_REGULAR, BR2_SSP_STRONG, or BR2_SSP_ALL is set, as
libssp.so provides __stack_chk_fail, and *_chk symbols, the
library must be copied to the target filesystem, like libgcc_s.so.

If BR2_SSP_NONE is set, there should be no need to copy it.

Signed-off-by: Yann Droneaud <ydroneaud@opteya.com>
---
 toolchain/toolchain-external/pkg-toolchain-external.mk | 4 ++++
 1 file changed, 4 insertions(+)

Comments

Romain Naour Sept. 7, 2019, 1:18 p.m. UTC | #1
Hi Yann,

Thanks for your patch.

Le 02/09/2019 à 08:37, Yann Droneaud a écrit :
> Unlike libgcc_s.so, libssp.so is not copied on the target file
> system. As it's available at link time, allowing packages such
> as sox to be linked against the library.
> 
> As it's not copied, running programs linked against libssp.so
> lead to failure such as the following:
> 
>   $ sox
>   sox: error while loading shared libraries: libssp.so.0: cannot open shared object file: No such file or directory
> 
>   $ rec
>   rec: error while loading shared libraries: libssp.so.0: cannot open shared object file: No such file or directory
> 
> If BR2_SSP_REGULAR, BR2_SSP_STRONG, or BR2_SSP_ALL is set, as
> libssp.so provides __stack_chk_fail, and *_chk symbols, the
> library must be copied to the target filesystem, like libgcc_s.so.
> 
> If BR2_SSP_NONE is set, there should be no need to copy it.

I'm unable to reproduce the issue with the following defconfig:

BR2_aarch64=y
BR2_SSP_ALL=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TARGET_GENERIC_GETTY_PORT="ttyAMA0"
BR2_SYSTEM_DHCP="eth0"
BR2_LINUX_KERNEL=y
BR2_LINUX_KERNEL_CUSTOM_VERSION=y
BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="4.19.16"
BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y
BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/qemu/aarch64-virt/linux.config"
BR2_LINUX_KERNEL_NEEDS_HOST_OPENSSL=y
BR2_PACKAGE_SOX=y
BR2_TARGET_ROOTFS_EXT2=y
BR2_TARGET_ROOTFS_EXT2_4=y
# BR2_TARGET_ROOTFS_TAR is not set

This defconfig use the external toolchain from ARM that provide SSP support.
But there is no libssp.so in this toolchain.

Also, libssp from gcc is disabled in Buildroot for internal toolchain since a while:
https://git.buildroot.net/buildroot/commit/?id=3b712a3d891bf23055a587fc518f7cd2139a6a09

In Buildroot, we are using libssp provided by the C library (glibc,
musl, uClibc-ng) when available. We are not using libssp from gcc.

Can you describe your issue ? Are you using a custom external toolchain ?

Best regards,
Romain

> 
> Signed-off-by: Yann Droneaud <ydroneaud@opteya.com>
> ---
>  toolchain/toolchain-external/pkg-toolchain-external.mk | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/toolchain/toolchain-external/pkg-toolchain-external.mk b/toolchain/toolchain-external/pkg-toolchain-external.mk
> index c3ddff263fe9..175a87756437 100644
> --- a/toolchain/toolchain-external/pkg-toolchain-external.mk
> +++ b/toolchain/toolchain-external/pkg-toolchain-external.mk
> @@ -114,6 +114,10 @@ endif
>  
>  TOOLCHAIN_EXTERNAL_LIBS += ld*.so* libgcc_s.so.* libatomic.so.*
>  
> +ifneq ($(BR2_SSP_NONE),y)
> +TOOLCHAIN_EXTERNAL_LIBS += libssp.so.*
> +endif
> +
>  ifeq ($(BR2_TOOLCHAIN_EXTERNAL_GLIBC)$(BR2_TOOLCHAIN_EXTERNAL_UCLIBC),y)
>  TOOLCHAIN_EXTERNAL_LIBS += libc.so.* libcrypt.so.* libdl.so.* libm.so.* libnsl.so.* libresolv.so.* librt.so.* libutil.so.*
>  ifeq ($(BR2_TOOLCHAIN_HAS_THREADS),y)
>
Thomas Petazzoni Sept. 7, 2019, 7:23 p.m. UTC | #2
Hello Romain,

On Sat, 7 Sep 2019 15:18:06 +0200
Romain Naour <romain.naour@smile.fr> wrote:

> I'm unable to reproduce the issue with the following defconfig:
> 
> BR2_aarch64=y
> BR2_SSP_ALL=y
> BR2_TOOLCHAIN_EXTERNAL=y
> BR2_TARGET_GENERIC_GETTY_PORT="ttyAMA0"
> BR2_SYSTEM_DHCP="eth0"
> BR2_LINUX_KERNEL=y
> BR2_LINUX_KERNEL_CUSTOM_VERSION=y
> BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="4.19.16"
> BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y
> BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/qemu/aarch64-virt/linux.config"
> BR2_LINUX_KERNEL_NEEDS_HOST_OPENSSL=y
> BR2_PACKAGE_SOX=y
> BR2_TARGET_ROOTFS_EXT2=y
> BR2_TARGET_ROOTFS_EXT2_4=y
> # BR2_TARGET_ROOTFS_TAR is not set
> 
> This defconfig use the external toolchain from ARM that provide SSP support.
> But there is no libssp.so in this toolchain.
> 
> Also, libssp from gcc is disabled in Buildroot for internal toolchain since a while:
> https://git.buildroot.net/buildroot/commit/?id=3b712a3d891bf23055a587fc518f7cd2139a6a09
> 
> In Buildroot, we are using libssp provided by the C library (glibc,
> musl, uClibc-ng) when available. We are not using libssp from gcc.
> 
> Can you describe your issue ? Are you using a custom external toolchain ?

Yes, I suspect Yann is using a custom external toolchain where the SSP
runtime support is provided by gcc and not by the C library.

Thomas
Yann Droneaud Sept. 9, 2019, 7:56 p.m. UTC | #3
Le samedi 07 septembre 2019 à 21:23 +0200, Thomas Petazzoni a écrit :
> Hello Romain,
> 
> On Sat, 7 Sep 2019 15:18:06 +0200
> Romain Naour <romain.naour@smile.fr> wrote:
> 
> > I'm unable to reproduce the issue with the following defconfig:
> > 
> > BR2_aarch64=y
> > BR2_SSP_ALL=y
> > BR2_TOOLCHAIN_EXTERNAL=y
> > BR2_TARGET_GENERIC_GETTY_PORT="ttyAMA0"
> > BR2_SYSTEM_DHCP="eth0"
> > BR2_LINUX_KERNEL=y
> > BR2_LINUX_KERNEL_CUSTOM_VERSION=y
> > BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="4.19.16"
> > BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y
> > BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/qemu/aarch64-
> > virt/linux.config"
> > BR2_LINUX_KERNEL_NEEDS_HOST_OPENSSL=y
> > BR2_PACKAGE_SOX=y
> > BR2_TARGET_ROOTFS_EXT2=y
> > BR2_TARGET_ROOTFS_EXT2_4=y
> > # BR2_TARGET_ROOTFS_TAR is not set
> > 
> > This defconfig use the external toolchain from ARM that provide SSP
> > support.
> > But there is no libssp.so in this toolchain.
> > 
> > Also, libssp from gcc is disabled in Buildroot for internal
> > toolchain since a while:
> > https://git.buildroot.net/buildroot/commit/?id=3b712a3d891bf23055a587fc518f7cd2139a6a09
> > 
> > In Buildroot, we are using libssp provided by the C library (glibc,
> > musl, uClibc-ng) when available. We are not using libssp from gcc.
> > 
> > Can you describe your issue ? Are you using a custom external
> > toolchain ?
> 
> Yes, I suspect Yann is using a custom external toolchain where the
> SSP
> runtime support is provided by gcc and not by the C library.
> 

I'm using linaro aarch64 ... but I remembered, incorrectly, having
check for other aarch64 toolchain: the other external toolchain don't
have libssp.

Regards.
Yann Droneaud Sept. 9, 2019, 8:11 p.m. UTC | #4
Hi,

Le samedi 07 septembre 2019 à 15:18 +0200, Romain Naour a écrit :

> 

> Thanks for your patch.
> 
> Le 02/09/2019 à 08:37, Yann Droneaud a écrit :
> > Unlike libgcc_s.so, libssp.so is not copied on the target file
> > system. As it's available at link time, allowing packages such
> > as sox to be linked against the library.
> > 
> > As it's not copied, running programs linked against libssp.so
> > lead to failure such as the following:
> > 
> >   $ sox
> >   sox: error while loading shared libraries: libssp.so.0: cannot
> > open shared object file: No such file or directory
> > 
> >   $ rec
> >   rec: error while loading shared libraries: libssp.so.0: cannot
> > open shared object file: No such file or directory
> > 
> > If BR2_SSP_REGULAR, BR2_SSP_STRONG, or BR2_SSP_ALL is set, as
> > libssp.so provides __stack_chk_fail, and *_chk symbols, the
> > library must be copied to the target filesystem, like libgcc_s.so.
> > 
> > If BR2_SSP_NONE is set, there should be no need to copy it.
> 
> I'm unable to reproduce the issue with the following defconfig:
> 
> BR2_aarch64=y
> BR2_SSP_ALL=y
> BR2_TOOLCHAIN_EXTERNAL=y
> BR2_TARGET_GENERIC_GETTY_PORT="ttyAMA0"
> BR2_SYSTEM_DHCP="eth0"
> BR2_LINUX_KERNEL=y
> BR2_LINUX_KERNEL_CUSTOM_VERSION=y
> BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="4.19.16"
> BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y
> BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/qemu/aarch64-
> virt/linux.config"
> BR2_LINUX_KERNEL_NEEDS_HOST_OPENSSL=y
> BR2_PACKAGE_SOX=y
> BR2_TARGET_ROOTFS_EXT2=y
> BR2_TARGET_ROOTFS_EXT2_4=y
> # BR2_TARGET_ROOTFS_TAR is not set
> 
> This defconfig use the external toolchain from ARM that provide SSP
> support.
> But there is no libssp.so in this toolchain.
> 
> Also, libssp from gcc is disabled in Buildroot for internal toolchain
> since a while:
> https://git.buildroot.net/buildroot/commit/?id=3b712a3d891bf23055a587fc518f7cd2139a6a09
> 
> In Buildroot, we are using libssp provided by the C library (glibc,
> musl, uClibc-ng) when available. We are not using libssp from gcc.
> 
> Can you describe your issue ? Are you using a custom external
> toolchain ?
> 

I'm sorry I wasn't specific enough. I had the issue with linaro aarch64
external toolchain. (For some reason I don't recall, I thought this
issue happen with other toolchain, but it's doesn't happen with ARM one
as you demonstrated, nor with Codesourcery one).

Regards.
Romain Naour Sept. 9, 2019, 9:23 p.m. UTC | #5
Hi Yann,

Le 09/09/2019 à 22:11, Yann Droneaud a écrit :
> Hi,
> 
> Le samedi 07 septembre 2019 à 15:18 +0200, Romain Naour a écrit :
> 
>>
> 
>> Thanks for your patch.
>>
>> Le 02/09/2019 à 08:37, Yann Droneaud a écrit :
>>> Unlike libgcc_s.so, libssp.so is not copied on the target file
>>> system. As it's available at link time, allowing packages such
>>> as sox to be linked against the library.
>>>
>>> As it's not copied, running programs linked against libssp.so
>>> lead to failure such as the following:
>>>
>>>   $ sox
>>>   sox: error while loading shared libraries: libssp.so.0: cannot
>>> open shared object file: No such file or directory
>>>
>>>   $ rec
>>>   rec: error while loading shared libraries: libssp.so.0: cannot
>>> open shared object file: No such file or directory
>>>
>>> If BR2_SSP_REGULAR, BR2_SSP_STRONG, or BR2_SSP_ALL is set, as
>>> libssp.so provides __stack_chk_fail, and *_chk symbols, the
>>> library must be copied to the target filesystem, like libgcc_s.so.
>>>
>>> If BR2_SSP_NONE is set, there should be no need to copy it.
>>
>> I'm unable to reproduce the issue with the following defconfig:
>>
>> BR2_aarch64=y
>> BR2_SSP_ALL=y
>> BR2_TOOLCHAIN_EXTERNAL=y
>> BR2_TARGET_GENERIC_GETTY_PORT="ttyAMA0"
>> BR2_SYSTEM_DHCP="eth0"
>> BR2_LINUX_KERNEL=y
>> BR2_LINUX_KERNEL_CUSTOM_VERSION=y
>> BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="4.19.16"
>> BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y
>> BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/qemu/aarch64-
>> virt/linux.config"
>> BR2_LINUX_KERNEL_NEEDS_HOST_OPENSSL=y
>> BR2_PACKAGE_SOX=y
>> BR2_TARGET_ROOTFS_EXT2=y
>> BR2_TARGET_ROOTFS_EXT2_4=y
>> # BR2_TARGET_ROOTFS_TAR is not set
>>
>> This defconfig use the external toolchain from ARM that provide SSP
>> support.
>> But there is no libssp.so in this toolchain.
>>
>> Also, libssp from gcc is disabled in Buildroot for internal toolchain
>> since a while:
>> https://git.buildroot.net/buildroot/commit/?id=3b712a3d891bf23055a587fc518f7cd2139a6a09
>>
>> In Buildroot, we are using libssp provided by the C library (glibc,
>> musl, uClibc-ng) when available. We are not using libssp from gcc.
>>
>> Can you describe your issue ? Are you using a custom external
>> toolchain ?
>>
> 
> I'm sorry I wasn't specific enough. I had the issue with linaro aarch64
> external toolchain. (For some reason I don't recall, I thought this
> issue happen with other toolchain, but it's doesn't happen with ARM one
> as you demonstrated, nor with Codesourcery one).

No problem at all!

Actually the toolchain have both ssp implementation: libssp from gcc and ssp
from Glibc!

ssp_cv_cc=yes
ssp_cv_lib=yes

I did a second build and removed libssp* files after extracting the toolchain
and sox is able to detect the ssp support from Glibc.

ssp_cv_cc=yes
ssp_cv_lib=no

Note: the ssp test from helpers.mk [1] only test without -lssp.
You can find additional information here [2].

So, you can patch sox to prefer the libc's ssp implementation and/or remove
those libssp libraries from a POST_EXTRACT_HOOKS in the
toolchain-external-linaro-aarch64 package.

[1]
https://git.buildroot.net/buildroot/tree/toolchain/helpers.mk?id=03fb00f2175cdb4565e26fcb9b3da1c1059de1bd#n424
[2] https://patchwork.openembedded.org/patch/150197/

Best regards,
Romain

> 
> Regards.
>
Yann Droneaud Sept. 23, 2019, 9:36 a.m. UTC | #6
Hi,

Le lundi 09 septembre 2019 à 23:23 +0200, Romain Naour a écrit :
> Le 09/09/2019 à 22:11, Yann Droneaud a écrit :
> > Le samedi 07 septembre 2019 à 15:18 +0200, Romain Naour a écrit :
> > 
> > > Thanks for your patch.
> > > 
> > > Le 02/09/2019 à 08:37, Yann Droneaud a écrit :
> > > > Unlike libgcc_s.so, libssp.so is not copied on the target file
> > > > system. As it's available at link time, allowing packages such
> > > > as sox to be linked against the library.
> > > > 
> > > > As it's not copied, running programs linked against libssp.so
> > > > lead to failure such as the following:
> > > > 
> > > >   $ sox
> > > >   sox: error while loading shared libraries: libssp.so.0:
> > > > cannot
> > > > open shared object file: No such file or directory
> > > > 
> > > >   $ rec
> > > >   rec: error while loading shared libraries: libssp.so.0:
> > > > cannot
> > > > open shared object file: No such file or directory
> > > > 
> > > > If BR2_SSP_REGULAR, BR2_SSP_STRONG, or BR2_SSP_ALL is set, as
> > > > libssp.so provides __stack_chk_fail, and *_chk symbols, the
> > > > library must be copied to the target filesystem, like
> > > > libgcc_s.so.
> > > > 
> > > > If BR2_SSP_NONE is set, there should be no need to copy it.
> > > 
> > > I'm unable to reproduce the issue with the following defconfig:
> > > 
> > > BR2_aarch64=y
> > > BR2_SSP_ALL=y
> > > BR2_TOOLCHAIN_EXTERNAL=y
> > > BR2_TARGET_GENERIC_GETTY_PORT="ttyAMA0"
> > > BR2_SYSTEM_DHCP="eth0"
> > > BR2_LINUX_KERNEL=y
> > > BR2_LINUX_KERNEL_CUSTOM_VERSION=y
> > > BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="4.19.16"
> > > BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y
> > > BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/qemu/aarch64-
> > > virt/linux.config"
> > > BR2_LINUX_KERNEL_NEEDS_HOST_OPENSSL=y
> > > BR2_PACKAGE_SOX=y
> > > BR2_TARGET_ROOTFS_EXT2=y
> > > BR2_TARGET_ROOTFS_EXT2_4=y
> > > # BR2_TARGET_ROOTFS_TAR is not set
> > > 
> > > This defconfig use the external toolchain from ARM that provide
> > > SSP
> > > support.
> > > But there is no libssp.so in this toolchain.
> > > 
> > > Also, libssp from gcc is disabled in Buildroot for internal
> > > toolchain
> > > since a while:
> > > https://git.buildroot.net/buildroot/commit/?id=3b712a3d891bf23055a587fc518f7cd2139a6a09
> > > 
> > > In Buildroot, we are using libssp provided by the C library
> > > (glibc,
> > > musl, uClibc-ng) when available. We are not using libssp from
> > > gcc.
> > > 
> > > Can you describe your issue ? Are you using a custom external
> > > toolchain ?
> > > 
> > 
> > I'm sorry I wasn't specific enough. I had the issue with linaro
> > aarch64
> > external toolchain. (For some reason I don't recall, I thought this
> > issue happen with other toolchain, but it's doesn't happen with ARM
> > one
> > as you demonstrated, nor with Codesourcery one).
> 
> No problem at all!
> 
> Actually the toolchain have both ssp implementation: libssp from gcc
> and ssp
> from Glibc!
> 
> ssp_cv_cc=yes
> ssp_cv_lib=yes
> 
> I did a second build and removed libssp* files after extracting the
> toolchain
> and sox is able to detect the ssp support from Glibc.
> 
> ssp_cv_cc=yes
> ssp_cv_lib=no
> 
> Note: the ssp test from helpers.mk [1] only test without -lssp.
> You can find additional information here [2].
> 
> So, you can patch sox to prefer the libc's ssp implementation and/or
> remove
> those libssp libraries from a POST_EXTRACT_HOOKS in the
> toolchain-external-linaro-aarch64 package.
> 

Thanks for the analysis and suggestion.

Unfortunately I don't have incentive/will/time to address this issue
anymore.

Regards.

Patch
diff mbox series

diff --git a/toolchain/toolchain-external/pkg-toolchain-external.mk b/toolchain/toolchain-external/pkg-toolchain-external.mk
index c3ddff263fe9..175a87756437 100644
--- a/toolchain/toolchain-external/pkg-toolchain-external.mk
+++ b/toolchain/toolchain-external/pkg-toolchain-external.mk
@@ -114,6 +114,10 @@  endif
 
 TOOLCHAIN_EXTERNAL_LIBS += ld*.so* libgcc_s.so.* libatomic.so.*
 
+ifneq ($(BR2_SSP_NONE),y)
+TOOLCHAIN_EXTERNAL_LIBS += libssp.so.*
+endif
+
 ifeq ($(BR2_TOOLCHAIN_EXTERNAL_GLIBC)$(BR2_TOOLCHAIN_EXTERNAL_UCLIBC),y)
 TOOLCHAIN_EXTERNAL_LIBS += libc.so.* libcrypt.so.* libdl.so.* libm.so.* libnsl.so.* libresolv.so.* librt.so.* libutil.so.*
 ifeq ($(BR2_TOOLCHAIN_HAS_THREADS),y)