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.web11.49771.1680251367148805320 for ; Fri, 31 Mar 2023 01:29:27 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@posteo.de header.s=2017 header.b=m+jF9tWF; 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 E7D7A2400CD for ; Fri, 31 Mar 2023 10:29:24 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1680251364; bh=WC94gvG+OEIcFBLzKi+JpgjiQqaKYmRMzHflx7z+dW4=; h=Subject:From:Cc:Date:To:From; b=m+jF9tWFqi/a/2zcaClSk6XOMge5M+iAsH3/AX6+o02U3p/S1o/e5GD9o/1b06E7S sph8oII/liFsFHGRQ1NPVs69KtfUuYOwb4tsQA+nlReTo5niTlqb9hdmKC/i9zobQ7 /cc+C5rDJ331vZmEoWX7BA8f/Cn3CK4h2QWQBr/oRai0nY0mfiB/JePJ9wajJ28S1Z cDvrEsZmp6oIVcEOzaCyKzPQF/PxBDdpgxXzEEK6JijO5Eyinn9lKBuMUXDECYbfpt AGeRsmayAq7KocmHkFugvqUxqV86ih1CUd0V81aJJQpMqg5mmjQbVLWCzFKwp9ApKc PORxqiJsWBR4g== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4PntkC41vTz9rxS; Fri, 31 Mar 2023 10:29:23 +0200 (CEST) Mime-Version: 1.0 (1.0) Subject: Re: [edk2-devel] [RFT PATCH v2 1/6] BaseTools/tools_def XCODE: Link X64 with -read_only_relocs suppress From: =?UTF-8?B?TWFydmluIEjDpHVzZXI=?= In-Reply-To: Cc: devel@edk2.groups.io, Gerd Hoffmann , Rebecca Cran , Andrew Fish Date: Fri, 31 Mar 2023 08:29:23 +0000 Message-Id: <943BFDDF-6EF6-42BD-9173-E3D26DCE0E0A@posteo.de> References: To: Ard Biesheuvel Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > On 31. Mar 2023, at 09:39, Ard Biesheuvel wrote: > =EF=BB=BFHi Marvin, >=20 > Thanks for the context. >=20 >=20 > On Thu, 30 Mar 2023 at 23:54, Marvin H=C3=A4user wrot= e: >>=20 >> Hi Ard, >>=20 >> Sorry, I cannot preserve the CC list as the groups.io interface doesn't s= eem to allow it. Can you please CC me on future revisions? >>=20 >> This patch will badly corrupt binaries. I cannot cite a source right now (= if you want me to, please remind me in your response, so I can look it up to= morrow), but for X64 (but not IA32, which is why this is enabled there), rel= ocs are relative to the first *writable* segment. In other words, any reloca= tion to __TEXT will badly corrupt binaries this way. >=20 > OMG. >=20 > I can't believe how buggy all this stuff is. But I can confirm that > the resulting binaries don't look right, even though they appear to > boot fine. Codegen does not change from the suppress flag, so there will be no addition= al text relocs beyond those you introduced. As they target the exception han= dler, I guess you=E2=80=99d need to actively provoke the broken code paths (= and may end up with a nice recursion :) ). > In particular, when I dump the PE relocations using > llvm-readobj --coff-basereloc, I don't see any relocations referring > to the .text section. >=20 >> In AUDK, we support this with two essential changes. The first is that we= always generate a writable dummy segment at the beginning of the address sp= ace [1], making the relocs relative to the image base. The second is that in= ocmtoc, our fork of the abandoned (and pretty badly-bugged) Apple mtoc, we e= xplicitly require this segment to be present and verify its virtual address i= s the minimum virtual address [2]. It is then omitted from the conversion pr= ocess [3]. I suggest you replicate these changes and fully switch to ocmtoc f= or XCODE5 builds. >=20 > I'm not going to do any of that. Instead, I am going to drop this > change, and do the following: >=20 > - modify the SecPei version of CpuExceptionHandlerLib to put the > vector templates in .data, as I proposed before. This works around the > issue, and given that SEC/PEI is assumed to be read-only anyway (as it > may execute in place from flash) and does not use page alignment for > the sections due to size constraints, it is reasonable to assume that > .text and .data will be mapped executable anyway. Well, that assumption is more than fair to make for the status quo platforms= , but this is just another rock in the way of doing things the right way (ev= en if it=E2=80=99s just VMs). Cc Gerd for an OVMF security perspective. Is PEI-time memory protection some= thing you=E2=80=99d be interested in in the future? >=20 > - update the version that performs the runtime fixups to only do so > when using the XCODE toolchain - we can phase that out once we drop > XCODE support. I agree if there=E2=80=99s an actual plan on doing that. We depend on XCODE5= downstream, but I think it would literally be easier for us if the upstream= version was dropped than rebasing against hacks that our slightly modded va= riant does not require. Cc Andrew and Rebecca. I don=E2=80=99t know anyone else who might still be u= sing XCODE5. Any objections to dropping it? If so, any plans to pick up my p= roposed changes instead? Best regards, Marvin=