From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ed1-f44.google.com (mail-ed1-f44.google.com [209.85.208.44]) by mx.groups.io with SMTP id smtpd.web10.9554.1661339148082570641 for ; Wed, 24 Aug 2022 04:05:48 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@gmail.com header.s=20210112 header.b=lnWUfyaP; spf=pass (domain: gmail.com, ip: 209.85.208.44, mailfrom: pedro.falcato@gmail.com) Received: by mail-ed1-f44.google.com with SMTP id 2so13527415edx.2 for ; Wed, 24 Aug 2022 04:05:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=3fx/nwt+9x4Fq1OM/VKKR38CpVIdZHMl1xEyH5MxPhc=; b=lnWUfyaPTbksv+7EJIMLVL2ANjAkADeX7LrySkF4HJF16h5pla0BB0HWQ4ShSaxhXW dJSvhdBnTHKG9dN5Hm4dA2qmfRAq1RRXyLOd12onQM8xtY1JfhNVhBE9+YhgFiUCpBKf nptD4fjgNRThNyxSXJ5x+ZrE+DllA4xlHFk0Uc1DmlxR6aIMgwnVd0MxAsi9LqV7lKvX djkLnFFLnJ9CVovlcRnjhSIyk0Lz59SnS5ZClagO61zRD0XqfvAk0TYOOJxbg64h7mFF tHaNcTSj81EnovI/hONOvPk/LNTyDktsHI1UJ1FjdgfbyfoMxt6Rbre1BgsHPMwaW122 xc6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=3fx/nwt+9x4Fq1OM/VKKR38CpVIdZHMl1xEyH5MxPhc=; b=eiJFVXup/lkQj/RHV4+1WrxDAofdz/dSfBaiTS0eeKNcev+PhMTZKS25n57/0V4/+r ddXQcgaiUrC91QxZ2EM5rFlG0Vn6XkbrMT8NDJwuJio6K3aHElu5XE19jddv+RjgCP/W a1miZOiV+OdAgtGym7lxko0/KGgj0n6lBiJqdtXPZDIu1tfCXQ0t0V2pg7zpmbMPn9Ld 8ky1Y101xbD8zWVoE59C8PCTDYnTLJH2hJN4hDk3kD7HPV4UMt+G3Gmxb1GCTdmZwXB7 vSMZg7gPmqwl6j4Ok+i4g+QF57qqCDNT+Y/vOUZSV51aCY1uQdj9OgE1e18DCk9VOow9 yyXw== X-Gm-Message-State: ACgBeo1Yg6VC/SjTYsFuGAXwWSWoicYFpkk0pUl/jwrjZ4M50+lLft5b KDVV1ixk1jQxqLhe9h1UyDabjLXLXkKvs6uALxo= X-Google-Smtp-Source: AA6agR6PFKBpHSWo7dJOF2no1+Cp2ngm9toht/Q97tEQbkh1UI3gPvhdv+6dZmet+AaajUMqOvBNhnpoK5xUe48Ytgc= X-Received: by 2002:aa7:cb83:0:b0:443:3f15:84fe with SMTP id r3-20020aa7cb83000000b004433f1584femr7346456edt.17.1661339146266; Wed, 24 Aug 2022 04:05:46 -0700 (PDT) MIME-Version: 1.0 References: <170CE325F85990DA.4359@groups.io> <5cd26f56-65c2-7994-04fa-1721fe9b1514@bsdio.com> <7c9dad7d-a229-cfb2-6a19-e63178713f72@bsdio.com> <16f27ae8-5553-1cf3-e6c9-79c0d03a868f@bsdio.com> In-Reply-To: <16f27ae8-5553-1cf3-e6c9-79c0d03a868f@bsdio.com> From: "Pedro Falcato" Date: Wed, 24 Aug 2022 12:05:33 +0100 Message-ID: Subject: Re: [edk2-devel] Problems building some Arm platforms (__stack_chk_guard/__stack_chk_fail, _GLOBAL_OFFSET_TABLE_) To: Rebecca Cran Cc: edk2-devel-groups-io , "Kinney, Michael D" , Leif Lindholm , Ard Biesheuvel , =?UTF-8?Q?Marvin_H=C3=A4user?= Content-Type: multipart/alternative; boundary="000000000000aa2dec05e6faa975" --000000000000aa2dec05e6faa975 Content-Type: text/plain; charset="UTF-8" Hi, So, what's your suggestion? Do you want me to add that to my package as well? There is obviously a huge problem with EDK2 build tools not knowing what a damn runtime library is. I personally don't think it's appropriate for me to say "I want my package built with the stack protector", particularly because my package shouldn't know what a damn stack protector is, and whoever is building it knows best, and because of that this should be dealt with by the build system itself (and no, setting it up in a platform dsc isn't a correct approach, since my package should be buildable standalone). And what if someone doesn't want the stack protector? Do they just create a new AARCH64_GCC5_NOSSP toolchain and build it with that? Do they just sed AARCH64_GCC5 to use -fno-stack-protector? Do they just limit themselves to toolchains without default SSP? IMO the correct way to go about things is to have the build tools automatically insert dependencies on runtime libraries and have a way to tag a toolchain such that you can easily selectively enable instrumentation (such as the SSP, UBSAN, ASAN, etc) and build them in any combination. Anyway, . I'll defer to your experience with the EDK2 build system for a solution. All the best, Pedro On Sat, Aug 20, 2022 at 4:06 AM Rebecca Cran wrote: > Other platform such as Platform/Qemu/SbsaQemu/SbsaQemu.dsc have: > > > # Add support for GCC stack protector > NULL|MdePkg/Library/BaseStackCheckLib/BaseStackCheckLib.inf > > > -- > > Rebecca Cran > > > On 8/19/22 20:34, Pedro Falcato wrote: > > I see the issue: We're not passing -fno-stack-protector to AARCH64 GCC > toolchains (although arguably we should just enable support for it...). Can > you try hacking up your tools_def to add -fno-stack-protector to > GCC_AARCH64_CC_FLAGS? It should fix your build issues. > > On Sat, Aug 20, 2022 at 2:51 AM Rebecca Cran wrote: > >> I'm using gcc version 9.4.0 (Ubuntu 9.4.0-1ubuntu1~20.04.1) on Ubuntu >> 20.04.4, from the Ubuntu repo. >> >> I'm building it with: >> >> >> export PACKAGES_PATH=$PWD/edk2:$PWD/edk2-platforms:$PWD/edk2-non-osi >> export WORKSPACE=$PWD >> export GCC5_AARCH64_PREFIX=aarch64-linux-gnu- >> >> . ./edk2/edksetup.sh >> build -p ./Features/Ext4Pkg/Ext4Pkg.dsc -a AARCH64 -b RELEASE -t GCC5 >> >> >> Some of the messages are: >> >> >> "aarch64-linux-gnu-gcc" -o >> /home/bcran/src/beaglebone/Build/Ext4Pkg/RELEASE_GCC5/AARCH64/Features/Ext4Pkg/Ext4Dxe/Ext4Dxe/DEBUG/Ext4Dxe.dll >> -Wl,--emit-relocs -nostdlib -Wl,--gc-sections -u _ModuleEntryPoint >> -Wl,-e,_ModuleEntryPoint,-Map,/home/bcran/src/beaglebone/Build/Ext4Pkg/RELEASE_GCC5/AARCH64/Features/Ext4Pkg/Ext4Dxe/Ext4Dxe/DEBUG/Ext4Dxe.map >> -z common-page-size=0x20 -z common-page-size=0x1000 -flto -Os >> -L/home/bcran/src/beaglebone/edk2/ArmPkg/Library/GccLto -llto-aarch64 >> -Wl,-plugin-opt=-pass-through=-llto-aarch64 -Wno-lto-type-mismatch >> -Wl,--start-group,@/home/bcran/src/beaglebone/Build/Ext4Pkg/RELEASE_GCC5/AARCH64/Features/Ext4Pkg/Ext4Dxe/Ext4Dxe/OUTPUT/static_library_files.lst,--end-group >> -g -Os -fshort-wchar -fno-builtin -fno-strict-aliasing -Wall -Werror >> -Wno-array-bounds -include AutoGen.h -fno-common -ffunction-sections >> -fdata-sections -DSTRING_ARRAY_NAME=Ext4DxeStrings -g -Os -fshort-wchar >> -fno-builtin -fno-strict-aliasing -Wall -Werror -Wno-array-bounds -include >> AutoGen.h -fno-common -mlittle-endian -fno-short-enums -fverbose-asm >> -funsigned-char -ffunction-sections -fdata-sections -Wno-address >> -fno-asynchronous-unwind-tables -fno-unwind-tables -fno-pic -fno-pie >> -ffixed-x18 -mcmodel=small -flto -Wno-unused-but-set-variable >> -Wno-unused-const-variable -D DISABLE_NEW_DEPRECATED_INTERFACES >> -Wl,--script=/home/bcran/src/beaglebone/edk2/BaseTools/Scripts/GccBase.lds >> -Wl,--defsym=PECOFF_HEADER_SIZE=0x228 -Wno-error >> /usr/lib/gcc-cross/aarch64-linux-gnu/9/../../../../aarch64-linux-gnu/bin/ld: >> /tmp/Ext4Dxe.dll.sETaOX.ltrans0.ltrans.o: in function >> `InternalAllocatePool.constprop.0': >> /home/bcran/src/beaglebone/edk2/MdePkg/Library/UefiMemoryAllocationLib/MemoryAllocationLib.c:368: >> undefined reference to `__stack_chk_guard' >> /usr/lib/gcc-cross/aarch64-linux-gnu/9/../../../../aarch64-linux-gnu/bin/ld: >> /tmp/Ext4Dxe.dll.sETaOX.ltrans0.ltrans.o: relocation >> R_AARCH64_ADR_PREL_PG_HI21 against symbol `__stack_chk_guard' which may >> bind externally can not be used when making a shared object; recompile with >> -fPIC >> /home/bcran/src/beaglebone/edk2/MdePkg/Library/UefiMemoryAllocationLib/MemoryAllocationLib.c:368:(.text.InternalAllocatePool.constprop.0+0xc): >> dangerous relocation: unsupported relocation >> /usr/lib/gcc-cross/aarch64-linux-gnu/9/../../../../aarch64-linux-gnu/bin/ld: >> /home/bcran/src/beaglebone/edk2/MdePkg/Library/UefiMemoryAllocationLib/MemoryAllocationLib.c:368: >> undefined reference to `__stack_chk_guard' >> /usr/lib/gcc-cross/aarch64-linux-gnu/9/../../../../aarch64-linux-gnu/bin/ld: >> /home/bcran/src/beaglebone/edk2/MdePkg/Library/UefiMemoryAllocationLib/MemoryAllocationLib.c:382: >> undefined reference to `__stack_chk_fail' >> /usr/lib/gcc-cross/aarch64-linux-gnu/9/../../../../aarch64-linux-gnu/bin/ld: >> /tmp/Ext4Dxe.dll.sETaOX.ltrans0.ltrans.o: in function >> `OrderedCollectionInsert.constprop.0': >> /home/bcran/src/beaglebone/edk2/MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.c:584: >> undefined reference to `__stack_chk_guard' >> >> -- >> Rebecca Cran >> >> >> On 8/19/22 18:46, Pedro Falcato wrote: >> >> Hi Rebecca, >> >> What EDK2 toolchain are you using? And how is your toolchain configured >> (or where did you get it from?)? It seems that it's trying to use the stack >> protector automatically... >> >> Thanks, >> Pedro >> >> >> On Sat, 20 Aug 2022, 00:40 Rebecca Cran, wrote: >> >>> ./Features/Ext4Pkg/Ext4Pkg.dsc is also failing - with errors about >>> __stack_chk_guard and __stack_chk_fail. >>> >>> >>> And I get an error from Andy Hayes' email: "Your message couldn't be >>> delivered to the recipient because you don't have permission to send to it." >>> >>> >>> -- >>> Rebecca Cran >>> >>> >>> On 8/19/22 17:35, Rebecca Cran wrote: >>> >>> I have an armplatbld.sh script that goes through and tries to build as >>> many of the Arm (AARCH64 and ARM) platforms in edk2-platforms as possible. >>> >>> I'm think this used to work for these, but I'm getting some errors now. >>> >>> I'm using edk2-platforms 46686eeb7e78efe603badd86f13777d9fb070fb8 and >>> edk2 e2ac68a23b4954d5c0399913a1df3dd9fd90315d. >>> >>> >>> Drivers/ASIX/Asix.dsc (fails with undefined references to __stack_chk_guard >>> and __stack_chk_fail) >>> >>> Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkPkg.dsc (fails with >>> undefined references to __stack_chk_guard and __stack_chk_fail) >>> Platform/Socionext/DeveloperBox/DeveloperBoxMm.dsc (fails with bad >>> definition for symbol '_GLOBAL_OFFSET_TABLE_'@0x72d8 or unsupported >>> symbol type. For example, absolute and undefined symbols are not >>> supported.) >>> >>> Drivers/StandaloneMmCpu/StandaloneMmCpu (fails with undefined >>> references to __stack_chk_guard and __stack_chk_fail) >>> >>> Platform/StandaloneMm/PlatformStandaloneMmPkg/PlatformStandaloneMmRpmb.dsc >>> (fails with bad definition for symbol '_GLOBAL_OFFSET_TABLE_'@0x72d8 or >>> unsupported symbol type. For example, absolute and undefined symbols are >>> not supported.) >>> >>> >>> -- >>> Rebecca Cran >>> >>> >>> > > -- > Pedro Falcato > > -- Pedro Falcato --000000000000aa2dec05e6faa975 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

So, what's your sugg= estion? Do you want me to add that to my package as well?

There is obviously a huge problem with EDK2 build tools not knowing= what a damn runtime library is. I personally don't think it's appr= opriate for me to say "I want my package built with the stack protecto= r", particularly because my package shouldn't know what a damn sta= ck protector is, and whoever is building it knows best, and because of that= this should be dealt with by the build system itself (and no, setting it u= p in a platform dsc isn't a correct approach, since my package should b= e buildable standalone). And what if someone doesn't want the stack pro= tector? Do they just create a new AARCH64_GCC5_NOSSP toolchain and build it= with that? Do they just sed AARCH64_GCC5 to use -fno-stack-protector? Do t= hey just limit themselves to toolchains without default SSP? IMO the correc= t way to go about things is to have the build tools automatically insert de= pendencies on runtime libraries and have a way to tag a toolchain such that= you can easily selectively enable instrumentation (such as the SSP, UBSAN,= ASAN, etc) and build them in any combination.

Any= way, </rant>. I'll defer to your experience with the EDK2 build s= ystem for a solution.

All the best,
Pedr= o

On Sat, Aug 20, 2022 at 4:06 AM Rebecca Cran <rebecca@bsdio.com> wrote:
=20 =20 =20

Other platform such as Platform/Qemu/SbsaQemu/SbsaQemu.dsc have:


=C2=A0 # Add support for GCC stack protector
=C2=A0 NULL|MdePkg/Library/BaseStackCheckLib/BaseStackCheckLib.inf


--

Rebecca Cran


On 8/19/22 20:34, Pedro Falcato wrote:
=20
I see the issue: We're not passing -fno-stack-protector to AARCH64 GCC toolchains (although arguably we should just enable support for it...). Can you try hacking up your tools_def to add -fno-stack-protector to GCC_AARCH64_CC_FLAGS? It should fix your build issues.

On Sat, Aug 20, 2022 at 2:51 AM Rebecca Cran <rebecca@bsdio.com> wrote:

I'm using gcc version 9.4.0 (Ubuntu 9.4.0-1ubuntu1~20.04.1) on Ubuntu 20.04.4, from the Ubuntu repo.

I'm building it with:


export PACKAGES_PATH=3D$PWD/edk2:$PWD/edk2-platforms:$PWD/edk2-non-o= si
export WORKSPACE=3D$PWD
export GCC5_AARCH64_PREFIX=3Daarch64-linux-gnu-

. ./edk2/edksetup.sh
build -p ./Features/Ext4Pkg/Ext4Pkg.dsc -a AARCH64 -b RELEASE -t GCC5


Some of the messages are:


"aarch64-linux-gnu-gcc" -o /home/bcran/src/beaglebone/Build/Ext4Pkg/RELEASE_GCC5/AARCH64/Features/Ext4= Pkg/Ext4Dxe/Ext4Dxe/DEBUG/Ext4Dxe.dll -Wl,--emit-relocs -nostdlib -Wl,--gc-sections -u _ModuleEntryPoint -Wl,-e,_ModuleEntryPoint,-Map,/home/bcran/src/beaglebone/Build/Ext4Pkg/RELE= ASE_GCC5/AARCH64/Features/Ext4Pkg/Ext4Dxe/Ext4Dxe/DEBUG/Ext4Dxe.map -z common-page-size=3D0x20 -z common-page-size=3D0x1000 -flto -Os -L/home/bcran/src/beaglebone/edk2/ArmPkg/Library/GccLto -llto-aarch64 -Wl,-plugin-opt=3D-pass-through=3D-llto-aarch64 -Wno-lto-type-mismatch -Wl,--start-group,@/home/bcran/src/beaglebone/Build/Ext4Pkg/RELEASE_GCC5/AA= RCH64/Features/Ext4Pkg/Ext4Dxe/Ext4Dxe/OUTPUT/static_library_files.lst,--en= d-group=C2=A0=C2=A0 -g -Os -fshort-wchar -fno-builtin -fno-strict-aliasing -Wall -Werror -Wno-array-bounds -include AutoGen.h -fno-common -ffunction-sections -fdata-sections -DSTRING_ARRAY_NAME=3DExt4DxeStrings -g -Os -fshort-wchar -fno-builtin -fno-strict-aliasing -Wall -Werror -Wno-array-bounds -include AutoGen.h -fno-common -mlittle-endian -fno-short-enums -fverbose-asm -funsigned-char -ffunction-sections -fdata-sections -Wno-address -fno-asynchronous-unwind-tables -fno-unwind-tables -fno-pic -fno-pie -ffixed-x18 -mcmodel=3Dsmall -flto -Wno-unused-but-set-variable -Wno-unused-const-variable -D DISABLE_NEW_DEPRECATED_INTERFACES -Wl,--script=3D/home/bcran/src/beaglebone/edk2/BaseTools/Scripts/GccBase.ld= s -Wl,--defsym=3DPECOFF_HEADER_SIZE=3D0x228 -Wno-error
/usr/lib/gcc-cross/aarch64-linux-gnu/9/../../../../aarch64-linux-gnu/bin/ld= : /tmp/Ext4Dxe.dll.sETaOX.ltrans0.ltrans.o: in function `InternalAllocatePool.constprop.0':
/home/bcran/src/beaglebone/edk2/MdePkg/Library/UefiMemoryAllocationLib/Memo= ryAllocationLib.c:368: undefined reference to `__stack_chk_guard'
/usr/lib/gcc-cross/aarch64-linux-gnu/9/../../../../aarch64-linux-gnu/bin/ld= : /tmp/Ext4Dxe.dll.sETaOX.ltrans0.ltrans.o: relocation R_AARCH64_ADR_PREL_PG_HI21 against symbol `__stack_chk_guard' which may bind externally can not be used when making a shared object; recompile with -fPIC
/home/bcran/src/beaglebone/edk2/MdePkg/Library/UefiMemoryAllocationLib/Memo= ryAllocationLib.c:368:(.text.InternalAllocatePool.constprop.0+0xc): dangerous relocation: unsupported relocation
/usr/lib/gcc-cross/aarch64-linux-gnu/9/../../../../aarch64-linux-gnu/bin/ld= : /home/bcran/src/beaglebone/edk2/MdePkg/Library/UefiMemoryAllocationLib/Memo= ryAllocationLib.c:368: undefined reference to `__stack_chk_guard'
/usr/lib/gcc-cross/aarch64-linux-gnu/9/../../../../aarch64-linux-gnu/bin/ld= : /home/bcran/src/beaglebone/edk2/MdePkg/Library/UefiMemoryAllocationLib/Memo= ryAllocationLib.c:382: undefined reference to `__stack_chk_fail'
/usr/lib/gcc-cross/aarch64-linux-gnu/9/../../../../aarch64-linux-gnu/bin/ld= : /tmp/Ext4Dxe.dll.sETaOX.ltrans0.ltrans.o: in function `OrderedCollectionInsert.constprop.0':
/home/bcran/src/beaglebone/edk2/MdePkg/Library/BaseOrderedCollectionRedBlac= kTreeLib/BaseOrderedCollectionRedBlackTreeLib.c:584: undefined reference to `__stack_chk_guard'

--
Rebecca Cran


On 8/19/22 18:46, Pedro Falcato wrote:
Hi Rebecca,

What EDK2 toolchain are you using? And how is your toolchain configured (or where did you get it from?)? It seems that it's trying to use the stack protector automatically...

Thanks,
Pedro


On Sat, 20 Aug 2022, 00:40 Rebecca Cran, <rebecca@bsdio.com> wrote:

./Features/Ext4Pkg= /Ext4Pkg.dsc is also failing - with errors about __stack_chk_guard and __stack_chk_fail.<= /p>


And I get an error from Andy Hayes' email: "Your message couldn't be delivered to the recipient because you don't have permission to send to it."


--
Rebecca Cran


On 8/19/22 17:35, Rebecca Cran wrote:

I have an armplatbld.sh script that goes through and tries to build as many of the Arm (AARCH64 and ARM) platforms in edk2-platforms as possible.

I'm think this used to work for these, but I'm getting some errors now.

I'm using edk2-platforms 46686eeb7e78efe603badd8= 6f13777d9fb070fb8 and edk2 e2ac68a23b4954d5c0399913a1df3dd9fd90315= d.


Drivers/ASIX/Asi= x.dsc (fails with undefined references to = = __stack_chk_guard and __stack_chk_fail)

Drivers/DisplayL= ink/DisplayLinkPkg/DisplayLinkPkg.dsc (= fails with undefined references to = __stack_chk_guard and __stack_chk_fail)
Platform/Socionex= t/DeveloperBox/DeveloperBoxMm.dsc (fails with bad definition for symbol '_GLOBAL_OFFSET_TABLE_'@0x72d8 = or unsupported symbol type.=C2=A0 For example, absolute and undefined symbols are not supported.)

Drivers/StandaloneMmCpu/Standal= oneMmCpu (<= span style=3D"font-family:monospace">fails with undefined references to __stack_chk_guard and = <= span style=3D"color:rgb(0,0,0);background-color:rgb(255,255,255)">__stack_chk_fail)<= /span>
Platform/StandaloneMm/Pl= atformStandaloneMmPkg/PlatformStandaloneMmRpmb.dsc (fails with bad definition for symbol '_GLOBAL_OFFSET_TABLE_= 9;@0x72d8 or unsupported symbol type.=C2=A0 For example, absolute and undefined symbols are not supported.)


--
Rebecca Cran

=20


--
Pedro Falcato


--
Pedro Falcato
--000000000000aa2dec05e6faa975--