From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by mx.groups.io with SMTP id smtpd.web10.29796.1676327843964248975 for ; Mon, 13 Feb 2023 14:37:24 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=P6CMX5mZ; spf=pass (domain: kernel.org, ip: 145.40.68.75, 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 ams.source.kernel.org (Postfix) with ESMTPS id 08A43B815DE for ; Mon, 13 Feb 2023 22:37:22 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C01DCC4339B for ; Mon, 13 Feb 2023 22:37:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1676327840; bh=QU7onXsmcW+Cif9EkwYWwWlNIaVsczIdNI6ckC1BLuU=; h=References:In-Reply-To:From:Date:Subject:To:From; b=P6CMX5mZbH+gVoCYbrOM+8D4IpR+DKrU1vJOXAyhl4pHhZZRhu0nL9aifO4SZr6ko OAGQKeRGnXAx2w3NDGdpgT/i1qIPmWD2eAojIWmrxZpE+fTltS4omW/07LJ8WFErKL D+EDULjF/pTZrl9ElnyIp9+P0brL3NFZdqNWaJG4exOvEAVncSel13ei45gqid9VS4 T3z9SJm2hxQ6fC6z/1kgbXhzqQ+Z0F0Kehb+QjHwr25vwkgJ+JGgUIJkkFcHwxUbBb puH6SkBuyKLglOEdAtmLKu215T0tVhIsh5m3UD1av2KI3FPVqXaTNvzsHsFL4q9Uh/ oMKJEQj+RMI6A== Received: by mail-lf1-f46.google.com with SMTP id h24so21028529lfv.6 for ; Mon, 13 Feb 2023 14:37:20 -0800 (PST) X-Gm-Message-State: AO0yUKVP+5723c8YyGeruc7n6uuhgq529dRfSui38YJa7zKONScp6VTj WMAY3Jo2x9s0cvauMQLYiOfJbL9+5UFCYLtHa0o= X-Google-Smtp-Source: AK7set+/3RZMpYBVXSZhLo8OThfIk3OQHqVHRPvbiqxaDu/uEnQef470uoSY21uC8JtNdO1VOlAj9zpaiT4kupy2bQI= X-Received: by 2002:a05:6512:41a:b0:4db:2ac3:a51a with SMTP id u26-20020a056512041a00b004db2ac3a51amr1638290lfk.29.1676327838772; Mon, 13 Feb 2023 14:37:18 -0800 (PST) MIME-Version: 1.0 References: <20230213151810.2301480-14-ardb@kernel.org> <18425.1676323010561670513@groups.io> <60CEC058-0002-45E3-AAD7-8D2BB24CFD57@posteo.de> In-Reply-To: <60CEC058-0002-45E3-AAD7-8D2BB24CFD57@posteo.de> From: "Ard Biesheuvel" Date: Mon, 13 Feb 2023 23:37:07 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [edk2-devel] [RFC 13/13] ArmVirtPkg/ArmVirtQemu: Enable hardware enforced W^X memory permissions To: devel@edk2.groups.io, mhaeuser@posteo.de Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 13 Feb 2023 at 23:23, Marvin H=C3=A4user wrote= : > > > On 13. Feb 2023, at 22:59, Ard Biesheuvel wrote: > > No, the only reason for adding -fpie here is to ensure that statically > initialized CONST pointers are emitted into .data.rel.ro and not into > .rodata, as this is under the control of the compiler. Although, > thinking about this, I wonder if we need to pass this to the linker > for codegen under LTO as well. But the PIE link itself should be > unnecessary here. > > > Oh, what fun. For some reason I thought it would be unsafe to specify -fp= ie but not -pie, but considering PIE relocs are ignored either way, this ac= tually makes perfect sense. Sorry! About that last part, the docs say: "It = is recommended that you compile all the files participating in the same lin= k with the same options and also specify those options at link time." [1], = so good catch! > > [1] https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#Optimize-Opt= ions > Yeah, but come to think of it, we pass the CC flags to the linker, so this should be covered. > But what about -fno-plt? > That doesn't make a difference in codegen on AArch64 - the same BL instruction is emitted along with the same type of relocation, and it is left up to the linker whether or not a PLT entry is emitted, and I don't think it will ever do that when generating a fully linked binary without -pie. > > It will if you pass -pie to the linker, which is why I would prefer to > avoid that. The main issue IIRC is that the emit-relocs section does > not cover the entries in the GOT table that also require relocation, > and are only covered by the PIE .rela section. For AArch64, I added > relaxation logic to GenFw to actually patch the instructions instead, > which is always possible given the absence of dynamic linking. > (d2687f23c909475d80cef32cdf9a5d121f0a9ae6, > 7b8f69d7e10628d473dd225224d8c2122d25a38d) > > > Yes, seen, very nice. I do wonder though why GOT entries are generated in= the first place when symbols are all local and data is within the PC-addre= ssable range. Just today, for a X64 build, I actually saw Clang relax a GOT= reference to __stack_chk_guard itself. > Yeah there are some strange corner cases, but in general, all symbol references are relative - it is precisely the 'special' symbol references that the compiler generates internally that sometimes get this wrong. > > This means that we don't have to care about compiler generated symbol > references, and so the relocs emitted by emit-relocs are sufficient, > and the additional ones emitted into .rela are unused anyway. The only > remaining absolute references are the ones resulting from statically > initialized globals, and those will either be in .data or in > .data.rel.ro (if -fpie is being used) > > > Right. thank you. > > Best regards, > Marvin >=20