From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by mx.groups.io with SMTP id smtpd.web11.50079.1680253181150762882 for ; Fri, 31 Mar 2023 01:59:41 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=oASw0jj6; spf=pass (domain: kernel.org, ip: 139.178.84.217, 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 dfw.source.kernel.org (Postfix) with ESMTPS id 90232625D6 for ; Fri, 31 Mar 2023 08:59:40 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 18C4BC43444 for ; Fri, 31 Mar 2023 08:59:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1680253179; bh=+7UpLXIz8MJp+VGR7E4g6Iv8YCicbK4HcUhop86ZreM=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=oASw0jj6FyH66Snq/IWKQbvqlBEyAwBhxmwNKaTNUME8QHLt2cWUDzEs4XnUBwQF5 1p7629vTOqQc/cFi+jRN0UGiFli1Duk08e70C260U+ileECuSqJdXbT/jeImdSVmrp j192QEf+43LoF5ckoYTwNMCJKaIO4UI66+Tz0Ja02niz0j3NznQXNqebZ0YLCYEiKw taVc9n1xIjn1wegxlSpGdFO0LuahuhYTSHMD2Hwc7+kgkvwVRYY/Akz014y7bXpv95 aTg6hcx7vFo1FTw29xKC5CVaSSa06rapdCDprhkXwiw9KlmKCSALjDt8VL2rTVjTPs KCsPd4THIXXOQ== Received: by mail-lf1-f54.google.com with SMTP id y15so27988729lfa.7 for ; Fri, 31 Mar 2023 01:59:38 -0700 (PDT) X-Gm-Message-State: AAQBX9fG/5Rwh6KPCueflqlNoCZvIdzLADhs/6lQBUnmABy73X93nRiI GVyKhGL3OxcUI0BsadNrqUPHSUwlYk89iaTsbMc= X-Google-Smtp-Source: AKy350ZwYFtksxIQEb/xstqWJ4VQueJ13OHXvTiT5mnD79uPzNisC7qFXNCAiIC0ozwfn4LGiEq6iXM/EaI3CWGdmvo= X-Received: by 2002:a19:ad09:0:b0:4eb:dcc:52ce with SMTP id t9-20020a19ad09000000b004eb0dcc52cemr5738573lfc.9.1680253177064; Fri, 31 Mar 2023 01:59:37 -0700 (PDT) MIME-Version: 1.0 References: <943BFDDF-6EF6-42BD-9173-E3D26DCE0E0A@posteo.de> In-Reply-To: <943BFDDF-6EF6-42BD-9173-E3D26DCE0E0A@posteo.de> From: "Ard Biesheuvel" Date: Fri, 31 Mar 2023 10:59:25 +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: devel@edk2.groups.io, mhaeuser@posteo.de Cc: Gerd Hoffmann , Rebecca Cran , Andrew Fish Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 31 Mar 2023 at 10:29, Marvin H=C3=A4user wrote= : > > > > On 31. Mar 2023, at 09:39, Ard Biesheuvel wrote: > > =EF=BB=BFHi Marvin, > > > > Thanks for the context. > > > > > > On Thu, 30 Mar 2023 at 23:54, Marvin H=C3=A4user w= rote: > >> > >> Hi Ard, > >> > >> Sorry, I cannot preserve the CC list as the groups.io interface doesn'= t seem to allow it. Can you please CC me on future revisions? > >> > >> This patch will badly corrupt binaries. I cannot cite a source right n= ow (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= relocation 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. > > Codegen does not change from the suppress flag, so there will be no addit= ional text relocs beyond those you introduced. As they target the exception= handler, I guess you=E2=80=99d need to actively provoke the broken code pa= ths (and may end up with a nice recursion :) ). > I understand that the codegen is the same. I was specifically talking about the PE relocations, which seem to be lacking entirely. > > 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 addres= s space [1], making the relocs relative to the image base. The second is th= at in ocmtoc, our fork of the abandoned (and pretty badly-bugged) Apple mto= c, we explicitly require this segment to be present and verify its virtual = address is the minimum virtual address [2]. It is then omitted from the con= version 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. > > Well, that assumption is more than fair to make for the status quo platfo= rms, but this is just another rock in the way of doing things the right way= (even if it=E2=80=99s just VMs). > How so? SEC and PEI could be mapped read-only today, it's just that we never bother. > Cc Gerd for an OVMF security perspective. Is PEI-time memory protection s= omething you=E2=80=99d be interested in in the future? > My WXN series for ARM maps all PEIMs read-only, and turns off shadowing entirely (which makes no sense for VMs). So we have most of what we need to do that, and this change has no bearing on that. > > > > - 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 XCO= DE5 downstream, but I think it would literally be easier for us if the upst= ream version was dropped than rebasing against hacks that our slightly modd= ed variant does not require. > > Cc Andrew and Rebecca. I don=E2=80=99t know anyone else who might still b= e using XCODE5. Any objections to dropping it? If so, any plans to pick up = my proposed changes instead? > I wouldn't mind dropping it. In fact, I'm wondering - given that you need to install nasm and iasl anyway - if it wouldn't make more sense to use the CLANGPDB toolchain on macOS, and avoid the mtoc mess entirely?