From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from nwk-aaemail-lapp02.apple.com (nwk-aaemail-lapp02.apple.com [17.151.62.67]) by mx.groups.io with SMTP id smtpd.web11.742.1571080282255020013 for ; Mon, 14 Oct 2019 12:11:22 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@apple.com header.s=20180706 header.b=ZscV9gml; spf=pass (domain: apple.com, ip: 17.151.62.67, mailfrom: afish@apple.com) Received: from pps.filterd (nwk-aaemail-lapp02.apple.com [127.0.0.1]) by nwk-aaemail-lapp02.apple.com (8.16.0.27/8.16.0.27) with SMTP id x9EJ6lOk032925; Mon, 14 Oct 2019 12:11:18 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=akY48BwfRZQqqQV4XHIbJ2U7EbYA9B7JyVJnkdTynoU=; b=ZscV9gmlqMTxtMxbgt7kkOy9rleZIyNfwzuxnO5gt5N1a9GIjMsDHr79RvNs4/dnBAL3 NqwhnxeDYt5k+pFmT4vyC58S+SFqWcwu622lYXQ254Xzyztu5UN3DzWqSWzu+c+3xv3I JUjoG8lw1W5N+GGWZgzJntf1hUhq25w3qWVgQrvmepN3ix4W9fs62jsbpZtJGv7TB4nv KNuh3B1BeCOe28yx26hE7IrU3bVSWnY0MZpdRLIjJ0fiZNMrre9tlGatHyH1VnozjgSK vc1K9If4N/zT7fhEhwq4UKdeOJ8QS/APU1c4OhXRkt7cnnl4WaoqpPSOqrbTROAJRvuu +Q== Received: from ma1-mtap-s01.corp.apple.com (ma1-mtap-s01.corp.apple.com [17.40.76.5]) by nwk-aaemail-lapp02.apple.com with ESMTP id 2vkbdvb29w-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 14 Oct 2019 12:11:18 -0700 Received: from nwk-mmpp-sz12.apple.com (nwk-mmpp-sz12.apple.com [17.128.115.204]) by ma1-mtap-s01.corp.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPS id <0PZD00CPDPARU1A0@ma1-mtap-s01.corp.apple.com>; Mon, 14 Oct 2019 12:11:17 -0700 (PDT) Received: from process_milters-daemon.nwk-mmpp-sz12.apple.com by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0PZD00900OW9HM00@nwk-mmpp-sz12.apple.com>; Mon, 14 Oct 2019 12:11:16 -0700 (PDT) X-Va-A: X-Va-T-CD: 07a9f7dd315dc6000695a0402a47d12d X-Va-E-CD: 17a6de702c0d9dcaf89f320d435a4bc6 X-Va-R-CD: 4287d1648b5c1ab4e136057a2bee17a6 X-Va-CD: 0 X-Va-ID: ede76cef-c386-4eab-8973-56f5aac9871d X-V-A: X-V-T-CD: 07a9f7dd315dc6000695a0402a47d12d X-V-E-CD: 17a6de702c0d9dcaf89f320d435a4bc6 X-V-R-CD: 4287d1648b5c1ab4e136057a2bee17a6 X-V-CD: 0 X-V-ID: 2b5ffb9d-e743-42d8-bd91-cac9e7c2ae38 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-10-14_09:,, signatures=0 Received: from [17.235.28.82] (unknown [17.235.28.82]) by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0PZD00KCZPAQNP90@nwk-mmpp-sz12.apple.com>; Mon, 14 Oct 2019 12:11:16 -0700 (PDT) Sender: afish@apple.com MIME-version: 1.0 (Mac OS X Mail 13.0 \(3594.4.17\)) Subject: Re: [edk2-devel] [RFC PATCH v2 38/44] UefiCpuPkg: Allow AP booting under SEV-ES From: "Andrew Fish" In-reply-to: <8aff5d64-1281-e36e-50b7-096c5dc0da05@redhat.com> Date: Mon, 14 Oct 2019 12:11:14 -0700 Cc: devel@edk2.groups.io, "Lendacky, Thomas" , Jordan Justen , Ard Biesheuvel , Mike Kinney , Liming Gao , Eric Dong , Ray Ni , "Singh, Brijesh" , =?utf-8?Q?Philippe_Mathieu-Daud=C3=A9?= Message-id: References: <81e310d1f2929f839cd166d1c7de6694220743b6.1568922729.git.thomas.lendacky@amd.com> <284e15f0-25ee-bb69-dcd1-09e146346c69@redhat.com> <8a8f839a-9e50-29da-06f7-50e3fc3b93c1@redhat.com> <851cc695-8902-3b07-4867-a101e0f9ee4f@amd.com> <8eb55d97-0ba3-c217-a160-c24730b9f036@amd.com> <635C113A-D0A2-4A11-AF9A-8A65BBE1C9BC@apple.com> <8aff5d64-1281-e36e-50b7-096c5dc0da05@redhat.com> To: Laszlo Ersek X-Mailer: Apple Mail (2.3594.4.17) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-10-14_09:,, signatures=0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable > On Oct 14, 2019, at 6:11 AM, Laszlo Ersek wrote: >=20 > On 10/12/19 08:42, Andrew Fish wrote: >> Laszlo, >>=20 >> For 2) this is very unfortunate. I think the root cause is for those >> of us who work on x86 hardware day to day we get programed that >> SEC/PEI is IA32 and DXE is X64, and this can lead to some unfortunate >> coding outcomes. >=20 > First I was confused by this; I didn't understand why the "bitness" of > SEC/PEI mattered here. >=20 > But, of course, you are right: if SEC/PEI are 32-bit, then the > problematic relocations are never generated by the compiler in the = first > place. >=20 Laszlo, The other "human" problem is people assume DXE always runs from memory = so they think that patching is OK. I've even see people use IA32 to mean = PEI on X64 platforms. So the implementation (32-bit PEI) leaks into the = architecture.=20 >> I'm guessing this code probably got ported from the DXE CPU driver or >> some other place that had no XIP assumptions. One option vs. patching >> is putting the relocations in the .data section. The only issue with >> that could be the need to align sections on page boundaries and that >> may take up too much space in XIP code. Perhaps we could only require >> the .data section relocations for XCODE, and map them to .text for >> the other toolchain? >=20 > In SEC, all sections of the binary are located in flash, aren't they? Yes.=20 > Why would it help if the relocations were placed in .data? Sorry if I was unclear. The Xcode linker (ld64) enforces a macOS x86_64 = ABI that makes it so even the image loader can't write the text section. = Thus you can't link an image that has relocations in the text section, = and there is no flag to ld64 to turn this behavior off. So the = workaround is to generate code like the compiler and don't have any = relocations in the text section. Moving the relocation from the text to = the data section is needed to make the Xcode linker (ld64) link the = code. if there are relocations in the text section then the link will = fail on Xcode builds.=20 When you are writing assembly code there is no restriction about placing = code in the data section. Generally we try to fix issues by converting = the code to use PC relative addressing, but a quick and dirty fix is to = change the code over to the data section. The cleaner solution is to = have a global in the data section that contains the relocatable address, = and that is like the simple example of the C code global I sent out.=20 > I'm reminded > of global variables in SEC, and those are not writable in SEC either. > (At least on QEMU.) I'm uncertain if this is somehow connected to > Cache-as-RAM, but if it is: QEMU does not support Cache-as-RAM. >=20 For SEC the relocations would have been applied at build time. The SEC = will have been linked at around zero, and when it was placed in the FV = it would have been relocated to its XIP location. For code running from = memory the EFI PE/COFF loader would apply the relocations as part of = loading the image. But non of the above works if your build fails due = to a linker error :(.=20 Thanks, Andrew Fish > Thanks > Laszlo