From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mout01.posteo.de (mout01.posteo.de [185.67.36.65]) by mx.groups.io with SMTP id smtpd.web10.29479.1676327017046008021 for ; Mon, 13 Feb 2023 14:23:37 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@posteo.de header.s=2017 header.b=eSbQnFau; spf=pass (domain: posteo.de, ip: 185.67.36.65, mailfrom: mhaeuser@posteo.de) Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 5D616240247 for ; Mon, 13 Feb 2023 23:23:35 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1676327015; bh=xZPp5OMI8OM17SY3LcEqrUpXiIy6l432peT1hTzfT+s=; h=From:Subject:Date:Cc:To:From; b=eSbQnFauiaAhOK7Pn7b9KmV+lAdHGO1gFTq1UtrvoZmmJgcqjvclzbBYiKRz3/Whz u8rFj+URWAzjVUDY5zNfWgvZc45dPz1ibE6/+HeLPPL4yeyA82GE+7O5hb+fix9TJp f2E8JU0HrYsj4awEeHDs9RnEzJcKeCZq6dGWUzv0Q97XEy5TevMcW0rAuiSSjSmGz2 IdvGi9oHuRAtqmzPdzfEtE9P10+YIG5GB0sc3MXrX7HKXeyLG3dPL22cewCfnVwuVe JLXzg0632YQhr7iwbQU//5W0pZCVTliPhgvCXsPr+OBDjqUXqdLJEFxBitLNIR0nIS /fp4t7RtxvClg== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4PFzPy2hFFz9rxD; Mon, 13 Feb 2023 23:23:34 +0100 (CET) From: =?UTF-8?B?TWFydmluIEjDpHVzZXI=?= Message-Id: <60CEC058-0002-45E3-AAD7-8D2BB24CFD57@posteo.de> Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Subject: Re: [edk2-devel] [RFC 13/13] ArmVirtPkg/ArmVirtQemu: Enable hardware enforced W^X memory permissions Date: Mon, 13 Feb 2023 22:23:24 +0000 In-Reply-To: Cc: edk2-devel-groups-io To: Ard Biesheuvel References: <20230213151810.2301480-14-ardb@kernel.org> <18425.1676323010561670513@groups.io> Content-Type: multipart/alternative; boundary="Apple-Mail=_EEE6AF01-FD5C-497B-B442-1CA3D645739D" --Apple-Mail=_EEE6AF01-FD5C-497B-B442-1CA3D645739D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 13. Feb 2023, at 22:59, Ard Biesheuvel wrote: >=20 > 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 = -fpie but not -pie, but considering PIE relocs are ignored either way, = this actually makes perfect sense. Sorry! About that last part, the docs = say: "It is recommended that you compile all the files participating in = the same link 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-Options But what about -fno-plt? >=20 > 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-addressable range. Just today, for a X64 build, I actually saw Clang = relax a GOT reference to __stack_chk_guard itself. >=20 > 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= --Apple-Mail=_EEE6AF01-FD5C-497B-B442-1CA3D645739D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On 13. Feb = 2023, at 22:59, Ard Biesheuvel <ardb@kernel.org> = 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 -fpie but not -pie, = but considering PIE relocs are ignored either way, this actually makes = perfect sense. Sorry! About that last part, the docs say: "It is = recommended that you compile all the files participating in the same = link with the same options and also specify those options at link time." = [1], so good catch!


But what about = -fno-plt?


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,
7b8f69d7e10628d4= 73dd225224d8c2122d25a38d)

= 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-addressable range. Just today, for a X64 build, I actually saw Clang = relax a GOT reference to __stack_chk_guard itself.


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
= --Apple-Mail=_EEE6AF01-FD5C-497B-B442-1CA3D645739D--