From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by mx.groups.io with SMTP id smtpd.web09.9830.1661340718901836984 for ; Wed, 24 Aug 2022 04:31:59 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=qNvLqhXk; spf=pass (domain: kernel.org, ip: 145.40.73.55, mailfrom: ardb@kernel.org) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sin.source.kernel.org (Postfix) with ESMTPS id AC45CCE223C for ; Wed, 24 Aug 2022 11:31:54 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9BDA3C43141 for ; Wed, 24 Aug 2022 11:31:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1661340712; bh=uRmGwhwzx3OFvioAfYD7jORly3y/UnK2fwZy1vlqxBQ=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=qNvLqhXkudB2hDvSGME1O8sWAaMU/+DmogyVTd4mpTpFVQVETocP8oFh9OSa9lVxe jWQsmhAUbk5V1Re0NYbAKxRRud9p1NTaCXsiBx2tGEwmIxYzEakdNU4XYowDPfK6p4 VwB6Meobj7PywQgmpiSYAF5ZhW8M29buyds+pDeQPyV6pEz60zdGEanS9FPrPRmZhE VWFYLVrWAxJX9kSBRhZt+uTBR1tTZod01UlkHplmQ5QhJRBUMM/7+hCNd2eKq4eSwS qtt0j6qsKD2FDAv4XPJao4EnEAbPqbFQ1eab/6urlTk7kDriEqD+yvH3jwZylb5eWi ylEgg6/S16E/A== Received: by mail-wm1-f53.google.com with SMTP id bd26-20020a05600c1f1a00b003a5e82a6474so668941wmb.4 for ; Wed, 24 Aug 2022 04:31:52 -0700 (PDT) X-Gm-Message-State: ACgBeo2k1KU24VvlSd8sCU0AFC5SxdMbQiciQKGWk2hYDVR7AKl38Vmx mxlOSsXyhEFhwD9rbx2irLwHMq/HSyTVpQbU2nk= X-Google-Smtp-Source: AA6agR6YUmQwxsTfSz0D9kfNnqqGwYgloh2pgoPrkegX0SVRt6SahvqLplqNRQ8HckT4q5cQw31nDo0K1eQTZhFTaG8= X-Received: by 2002:a05:600c:3586:b0:3a5:fb24:a205 with SMTP id p6-20020a05600c358600b003a5fb24a205mr5106155wmq.77.1661340710723; Wed, 24 Aug 2022 04:31:50 -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: From: "Ard Biesheuvel" Date: Wed, 24 Aug 2022 13:31:39 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [edk2-devel] Problems building some Arm platforms (__stack_chk_guard/__stack_chk_fail, _GLOBAL_OFFSET_TABLE_) To: Pedro Falcato Cc: Rebecca Cran , edk2-devel-groups-io , "Kinney, Michael D" , Leif Lindholm , Ard Biesheuvel , =?UTF-8?Q?Marvin_H=C3=A4user?= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 24 Aug 2022 at 13:05, Pedro Falcato wrote= : > > Hi, > > So, what's your suggestion? Do you want me to add that to my package as w= ell? > > There is obviously a huge problem with EDK2 build tools not knowing what = a damn runtime library is. The real problem here is that someone decided that, instead of implementing proper support for PE/COFF executables in binutils and GCC [for certain architectures: most notably ARM and arm64 today, but also Itanium], it is OK to use a toolchain that targets an entirely different execution environment (ELF on Linux, for example), and hack some scaffolding around its output looks like PE/COFF to the extent required by EFI. Of course, this entirely falls apart with any kind of runtime library: this also affects memcpy() and memset(), for instance, and on ARM32, a slew of __aeabi_xxx runtime routines that the architecture specifies for ELF targets. And we cannot actually use the toolchain provided versions either, as they may contain syscalls or other codegen that depends on the toolchain's target ABI. > I personally don't think it's appropriate for me to say "I want my packag= e built with the stack protector", particularly because my package shouldn'= t know what a damn stack protector is, and whoever is building it knows bes= t, 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 m= y package should be buildable standalone). And what if someone doesn't want= the stack protector? Do they just create a new AARCH64_GCC5_NOSSP toolchai= n and build it with that? Do they just sed AARCH64_GCC5 to use -fno-stack-p= rotector? Do they just limit themselves to toolchains without default SSP? = IMO the correct way to go about things is to have the build tools automatic= ally insert dependencies on runtime libraries and have a way to tag a toolc= hain such that you can easily selectively enable instrumentation (such as t= he SSP, UBSAN, ASAN, etc) and build them in any combination. > In my opinion, adding stack protector support like this was a mistake. What we need is a single intrinsics library, where every arch/toolchain combo can provide all the stuff that might be needed. If structured correctly (i.e., use separate objects and rely on LD garbage collection), this will only pull in the code that is actually needed at link time, and will get rid of these errors. As for overriding the use of the stack protector: this can be done from a DSC file, by appending -f[no]-stack-protector to the global CC flags. In general, choice of compiler options is a DSC level choice, so it is not something you typically need to worry about at the package level. Building the *SAN pieces like this requires extensive runtime support anyway, and so I don't see those being supported soon - someone needs to port the runtime library first. > Anyway, . I'll defer to your experience with the EDK2 build system= for a solution. > I propose adding the library class resolution to the DSC - it will only take effect when the stack protector is actually enabled. Then, if you feel generous, you can add a DEFINE that can be set from the build command line to control stack protector support, but I personally wouldn't bother.