From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by mx.groups.io with SMTP id smtpd.web12.6280.1627035202518693194 for ; Fri, 23 Jul 2021 03:13:22 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=D8kCEDNM; spf=pass (domain: kernel.org, ip: 198.145.29.99, mailfrom: ardb@kernel.org) Received: by mail.kernel.org (Postfix) with ESMTPSA id 116E960EFD for ; Fri, 23 Jul 2021 10:13:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1627035202; bh=tFrUqE2gmdOecLAVZtyiRJ2rZbEII6P3LZFYfLkT/oE=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=D8kCEDNMT7FpA8bNMlVtMWMJLXYwkpSW6ZPaFOx03TFgrQkeB+PgCJZoCdnWMOW/v aX4wnTUQg//wCQfkMN5nxAAVh4pA5gvePeTVuRukNZi2Ov8RfSY4MxWZQHezVFb1NV ybTrkjD274xuUbI39fab8usv84N2kGLKILTexv3rFYYRIByESdlQ67oI/99m639bNQ gGMLc2gJMyPjL+PkD7sFcHSSKp1Kmw54hfTb33n+48LyfTINCUuDLG3RvHhhES7V/r roq7cV/Bd706qbeIAz3I4OF+cljO8+9dWGly5l5RglZ3HAZL0wm0266w1dCfcyna7J 7UY2iH4EdrhXg== Received: by mail-oi1-f172.google.com with SMTP id t128so1326359oig.1 for ; Fri, 23 Jul 2021 03:13:22 -0700 (PDT) X-Gm-Message-State: AOAM533U/uztsuhh2j2e9OSNsVhWSG0z5wsudStYzo13oShuFWwco1v9 jfGmekBBKQ6te+Zwtj/1oBiD8AteySTck79gBZo= X-Google-Smtp-Source: ABdhPJxfj6LdwJJl1eQW6qoULsehP1folElS8S6BCAGbb3ZsLyqAwmAmaoXAoTSaBDRJPBqG1P1mYqYiTcpGe0bGXTo= X-Received: by 2002:aca:5a04:: with SMTP id o4mr2508425oib.33.1627035201381; Fri, 23 Jul 2021 03:13:21 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Ard Biesheuvel" Date: Fri, 23 Jul 2021 12:13:10 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: ArmVirt and Self-Updating Code To: =?UTF-8?Q?Marvin_H=C3=A4user?= Cc: Bret Barkelew , Thomas Abraham , "Ard Biesheuvel (TianoCore)" , "Lindholm, Leif" , Laszlo Ersek , Sami Mujawar , "devel@edk2.groups.io" , nd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 23 Jul 2021 at 11:55, Marvin H=C3=A4user wrote= : > > 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 Erse= k; 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 se= ems 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 understand. > >> > > "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. > jumps, calls, etc; ARM docs don't spill it out, but vaguely imply this > always is possible?), and The primary reason to use -fpie and PIE linking is to ensure that the resulting ELF executable contains a RELA section that describes every location in the binary where a memory address is stored that needs to be updated according to the actual placement in memory. The side effect of -fpie is that position independent global references are emitted (i.e., ADRP/ADD instructions which are relative to the program counter). However, the AArch64 compiler uses those by default anyway, so for this it is not strictly needed. > 2) emit a GOT, which ends up being converted to PE/COFF Relocations (-> > self-relocation), for global data that cannot be referenced relatively? > Is there any way to know/force that no symbol in GOT is accessed up > until the end of the self-relocation process? > It is not really a GOT. Actually, a GOT is undesirable, as it forces global variables to be referenced via an absolute address, even when a relative reference could be used. For instance, a statically initialized pointer always carries an absolute address, and so it always needs an entry in the RELA table E.g., int foo =3D 10; // external linkage static int *bar =3D &foo; In this case, there is no way to use relative addressing because the address of foo is taken at build time. However, if bar would be something like static int *bar() { return &foo; } the address is only taken at runtime, and the compiler can use a relative reference instead, and no RELA entry is needed. With a GOT, we force the compiler to allocate a variable that holds the absolute address, which we would prefer to avoid. > >> =E2=80=9CNow, StandaloneMmPkg has similar (self-)relocation code too:h= ttps://github.com/tianocore/edk2/blob/17143c4837393d42c484b42d1789b85b2cff1= aaf/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/AArch64/StandaloneMm= CoreEntryPoint.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/SetPer= missions.c#L131-L158 > > As per your comments below, I think SecCore should not be located here. > Is the Standalone MM core of *type* SecCore in the FFS (without *being* > SecCore)? This confused me the most. > If the FFS SecCore section type is used here, it does not mean that the image is a SEC image in the strict PI sense. Perhaps we were just too lazy to add a new type to the FFS spec? > >> =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 Stand= alone 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 > 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! > My pleasure.