From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mout02.posteo.de (mout02.posteo.de [185.67.36.66]) by mx.groups.io with SMTP id smtpd.web09.6314.1627034101923201692 for ; Fri, 23 Jul 2021 02:55:02 -0700 Authentication-Results: mx.groups.io; dkim=fail reason="body hash did not verify" header.i=@posteo.de header.s=2017 header.b=oegZ1ZLi; spf=pass (domain: posteo.de, ip: 185.67.36.66, mailfrom: mhaeuser@posteo.de) Received: from submission (posteo.de [89.146.220.130]) by mout02.posteo.de (Postfix) with ESMTPS id BBAC2240106 for ; Fri, 23 Jul 2021 11:54:58 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1627034098; bh=gTHbGRKNOXkMdUicwSRjKOgXcNL6KWY0fy7B6Bk3eOc=; h=From:Subject:To:Cc:Date:From; b=oegZ1ZLin8zfZ8X+eWLSrnAD9EkP3DhDnsrkzLS2dJGniKRvcHUzskCjs1DIJ4V8D wxgAdxSwQnJmnzserHSoOYzezfizJvlBqT32qX5AyKsJJ7dKDelhlkc5Eh8Fa1RQS6 0VF4cIYYIPetZmJYgme7Itqdh9iykcNFGE5gDzbznmxfOvT/DoR4gHr60Pnql1diam clD1RahQaX587v+U5g3PiSUA4hJYbr1y5NCL7aD9gXElz9cgtui4L4x9nD5IdzpVgm Dd5kcEx4EkJD+S7jpHklH97ifOsqEY/kidWbZvbjU1rwbsTtlth5BdeUAAp67WwSG9 AFXxMymguJGsA== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4GWPnD1WPSz6tmK; Fri, 23 Jul 2021 11:54:56 +0200 (CEST) From: =?UTF-8?B?TWFydmluIEjDpHVzZXI=?= Subject: Re: ArmVirt and Self-Updating Code To: Ard Biesheuvel , Bret Barkelew Cc: Thomas Abraham , "Ard Biesheuvel (TianoCore)" , "Lindholm, Leif" , Laszlo Ersek , Sami Mujawar , "devel@edk2.groups.io" , nd References: Message-ID: Date: Fri, 23 Jul 2021 09:54:55 +0000 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 22.07.21 17:14, Ard Biesheuvel wrote: > On Thu, 22 Jul 2021 at 16:54, Bret Barkelew wrote: >> Expanding audience to the full dev list=E2=80=A6 >> >> See below=E2=80=A6 >> >> >> >> - Bret >> >> >> >> From: Thomas Abraham >> Sent: Wednesday, July 7, 2021 11:07 PM >> To: Bret Barkelew; Ard Biesheuvel (TianoCore); Lindholm, Leif; Laszlo = Ersek; Marvin H=C3=A4user; Sami Mujawar >> Cc: nd >> Subject: [EXTERNAL] RE: ArmVirt and Self-Updating Code >> >> >> >> + Sami >> >> >> >> From: Bret Barkelew >> Sent: Thursday, July 8, 2021 11:05 AM >> To: Thomas Abraham; Ard Biesheuvel (TianoCore)= ; Lindholm, Leif; Laszlo Er= sek; Marvin H=C3=A4user >> Subject: ArmVirt and Self-Updating Code >> >> >> >> All, >> >> >> >> Marvin asked me a question on the UEFI Talkbox Discord that=E2=80=99s = a little beyond my ken=E2=80=A6 >> >> >> >> =E2=80=9CThere is self-relocating code in ArmVirtPkg: >> >> https://github.com/tianocore/edk2/blob/17143c4837393d42c484b42d1789b85= b2cff1aaf/ArmVirtPkg/PrePi/PrePi.c#L133-L165 >> >> According to comments in the ASM, it seems like this is for Linux-base= d RAM boot (I saw further stuff for KVM, so it makes sense I guess?). It = seems unfortunate it cannot be mapped into a known address range so that = self-relocation is not necessary, but that's out of my scope to understan= d. >> > "Mapping" implies that the MMU is on, but this code boots with the MMU > off. Unlike x86, ARM does not define any physical address ranges that > are guaranteed to be backed by DRAM, so a portable image either needs > to be fully position independent, or carry the metadata it needs to > relocate itself as it is invoked. And I understood it right that the idea is to use "-fpie" to 1) have all control flow instructions be position-independent (i.e.=20 jumps, calls, etc; ARM docs don't spill it out, but vaguely imply this=20 always is possible?), and 2) emit a GOT, which ends up being converted to PE/COFF Relocations (->=20 self-relocation), for global data that cannot be referenced relatively?=20 Is there any way to know/force that no symbol in GOT is accessed up=20 until the end of the self-relocation process? >> =E2=80=9CNow, StandaloneMmPkg has similar (self-)relocation code too:h= ttps://github.com/tianocore/edk2/blob/17143c4837393d42c484b42d1789b85b2cf= f1aaf/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/AArch64/Standalo= neMmCoreEntryPoint.c#L379-L386 >> >> Because I cannot find such elsewhere, I assume it must be for the same= ARM virtualised environment as above. > No. > >> The binary it applies the Relocations to is documented to be the Stand= alone MM core, but in fact SecCore is located: >> >> https://github.com/tianocore/edk2/blob/17143c4837393d42c484b42d1789b85= b2cff1aaf/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/AArch64/SetP= ermissions.c#L131-L158 As per your comments below, I think SecCore should not be located here.=20 Is the Standalone MM core of *type* SecCore in the FFS (without *being*=20 SecCore)? This confused me the most. >> =E2=80=9CThis yields the following questions to me: >> >> 1) What even invokes Standalone MM on ARM? It is documented it is spaw= ned during SEC, but I could not find any actual invocation. >> > It is not spawned by the normal world code that runs UEFI. It is a > secure world component that runs in a completely different execution > context (TrustZone). The code does run with the MMU enabled from the > start, but running from an a priori fixed offset was considered to be > a security hazard, so we added self relocation support. > > The alternative would have been to add metadata to the StMmCore > component that can be interpreted by the secure world component that > loads it, but this would go beyond any existing specs, and make > portability more problematic. > >> 2) Why does Standalone MM (self-)relocation locate SecCore? Should it = not already have been relocated with the code from ArmPlatformPkg? Is Sta= ndalone MM embedded into ARM SecCore? >> > No and no. Standalone MM has nothing to do with the code that runs as > part of UEFI itself. ArmPlatformPkg is completely separate from > StandaloneMmPkg. > >> 3) Why is SecCore the only module relocated? Are all others guaranteed= to be "properly" loaded? >> > SecCore contains a PE/COFF loader, so all subsequent modules are > loaded normally. This is similar to the ArmVirtQemuKernel > self-relocating SEC module, which only relocates itself in this > manner, and relies on standard PE/COFF metadata for loading other > modules. Interesting... this definitely is vastly different from the x86 side of=20 things. I think most things became very clear. Thanks a lot! >> 4) Is there maybe some high-level documented about the ARM boot flow? = It seems to be significantly different from the x86 routes quite vastly.=E2= =80=9D >> > trustedfirmware.org may have some useful documentation. I'll check it some time, hopefully this weekend. Thanks! Best regards, Marvin >> Hoping that one of you could get me closer to an answer for him. Also = happy to take this to the greater mailing list, but thought I=E2=80=99d a= void churn. >> >> >> >> Thanks in advance! >> >> - Bret >> >> >> >>