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.web11.49182.1680248396193791148 for ; Fri, 31 Mar 2023 00:39:56 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=n6uP83Ow; 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 1F405B82C7D for ; Fri, 31 Mar 2023 07:39:54 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C6336C433D2 for ; Fri, 31 Mar 2023 07:39:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1680248392; bh=hPRAmIdcjT6RJUqxQdt5sdgnT4jfbNue2PBpR4TMLU0=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=n6uP83Owpk2Uijmq0u93G37o7yB/rSRnJsT9+XTEew0Z9+iT4qbGoisvoDfE2jtRA BncU0aJALU7NeqYH9EESAwPRwlk4i4bi7z2chbktzDWFHcDpoCKYoRg7TzWFc9gGRC Gp0TCEHO1ckRXCWOgVIgWYTj8PBp8ThLs2EZd12eQfQMcPDmFfU61nXYKBpddgMTlk 8+Jo8fpKy1YcQG54yC7XA/cZeyEePdmrZAJ/q3ftppj1vfA23/RO/k2ckExpXMaFAd HbjFegCxqpJtx9dUzBVt/TWDQ212Ictm7/MZXGe0Q8fKQFoezwiT9x+03j/M7pvYQ3 BEYYNRjcJnDlA== Received: by mail-lf1-f54.google.com with SMTP id y15so27765653lfa.7 for ; Fri, 31 Mar 2023 00:39:52 -0700 (PDT) X-Gm-Message-State: AAQBX9coVN1MM9sRyVN7VL1/ducACyAP8ud3nkIwOdAonsPHEmAKJyEr Z2kKUxTZ8kzoUs5dLCITkkPgZ4OJT3abYyu5wOQ= X-Google-Smtp-Source: AKy350Zeny0mvZhc66EIo375tzN+FgUy4sDMIjD4L303Vl8H6SDWk57qARxwWa98PrrZ73k0/3of8GAsDyt4iyp7148= X-Received: by 2002:ac2:522e:0:b0:4dc:4b06:9d67 with SMTP id i14-20020ac2522e000000b004dc4b069d67mr7719495lfl.9.1680248390785; Fri, 31 Mar 2023 00:39:50 -0700 (PDT) MIME-Version: 1.0 References: <20230330212101.1566931-2-ardb@kernel.org> <13330.1680213242478608984@groups.io> In-Reply-To: <13330.1680213242478608984@groups.io> From: "Ard Biesheuvel" Date: Fri, 31 Mar 2023 09:39:39 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [edk2-devel] [RFT PATCH v2 1/6] BaseTools/tools_def XCODE: Link X64 with -read_only_relocs suppress To: =?UTF-8?Q?Marvin_H=C3=A4user?= Cc: devel@edk2.groups.io Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Marvin, Thanks for the context. On Thu, 30 Mar 2023 at 23:54, Marvin H=C3=A4user wrote= : > > Hi Ard, > > 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? > > 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 = tomorrow), but for X64 (but not IA32, which is why this is enabled there), = relocs are relative to the first *writable* segment. In other words, any re= location to __TEXT will badly corrupt binaries this way. > OMG. 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. In particular, when I dump the PE relocations using llvm-readobj --coff-basereloc, I don't see any relocations referring to the .text section. > 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 s= pace [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 explicitly require this segment to be present and verify its virtual add= ress is the minimum virtual address [2]. It is then omitted from the conver= sion process [3]. I suggest you replicate these changes and fully switch to= ocmtoc for XCODE5 builds. > I'm not going to do any of that. Instead, I am going to drop this change, and do the following: - 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. - 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.