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.web10.8829.1627049384986254888 for ; Fri, 23 Jul 2021 07:09:45 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=jAU8wUnn; spf=pass (domain: kernel.org, ip: 198.145.29.99, mailfrom: ardb@kernel.org) Received: by mail.kernel.org (Postfix) with ESMTPSA id 273F460EFD for ; Fri, 23 Jul 2021 14:09:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1627049384; bh=nByzMIi08Jompon3IGvVbkm2xUgcz98Y2KDbrCtzzhQ=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=jAU8wUnnTSn7NhgHcdbjqnTLDpoHCXjFUmm97Xq158o+q/3xnlpjlg22EOAHYlxDn +XXEHY9Jzxw+OKpc8u1mNnELYspHjdxz4hXVEx1a9L6HLs56AJMOp0chPnao3Sc0mE r3mT7YYoUFZEkjTqhXI0NfhilCfwYM+8jOzNyheeR/oiKdkhbNjU9Uwb/lPNqFMSiV HcWTmxcVmcW9musQzif/LSx2FrOF7GMB4AtzkuOXwsocnspR/hvSHrshIkUCUfgtnA xwWpZmVNbLWMtsbfoBxHV7nu0iAfFuDo7y581BBviMkeevd+h+gScWDGYomw5q48zi DuWjoU0JpU+Tw== Received: by mail-oi1-f176.google.com with SMTP id q6so1925814oiw.7 for ; Fri, 23 Jul 2021 07:09:44 -0700 (PDT) X-Gm-Message-State: AOAM533mDI6LLAHhCqyH/0hkSlaFvy/C49uOeXmuNc1VK+EE0o9RnLvd 17RjVWGYNO6urbZhEXwaHYsLNq10EdKa7IOXDaI= X-Google-Smtp-Source: ABdhPJxV94ZkwDrCwq3IM8C4XzYDVQAAQY6T65H1pnLiyWRfqO/XHxikqlgg0z4nXRzeM5qNc3hsTdtXlm4z2JaHTLM= X-Received: by 2002:aca:5a04:: with SMTP id o4mr3100578oib.33.1627049383450; Fri, 23 Jul 2021 07:09:43 -0700 (PDT) MIME-Version: 1.0 References: <36b32106-da0e-bfd5-10cf-6c9bb86173d1@posteo.de> In-Reply-To: <36b32106-da0e-bfd5-10cf-6c9bb86173d1@posteo.de> From: "Ard Biesheuvel" Date: Fri, 23 Jul 2021 16:09:32 +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 12:47, Marvin H=C3=A4user wrote= : > > On 23.07.21 12:13, Ard Biesheuvel wrote: > > On Fri, 23 Jul 2021 at 11:55, Marvin H=C3=A4user w= rote: > >> 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; Laszl= o 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 (TianoCor= e); 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=99= s a little beyond my ken=E2=80=A6 > >>>> > >>>> > >>>> > >>>> =E2=80=9CThere is self-relocating code in ArmVirtPkg: > >>>> > >>>> https://github.com/tianocore/edk2/blob/17143c4837393d42c484b42d1789b= 85b2cff1aaf/ArmVirtPkg/PrePi/PrePi.c#L133-L165 > >>>> > >>>> According to comments in the ASM, it seems like this is for Linux-ba= sed 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 se= lf-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 MM= U > >>> 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. > > Hmm, the GCC docs say a GOT is used for "all constant addresses" (I took > it as "absolute"?), it is kind of vague. I understood it this way: > 1) no-pie emits relocations that can target the .text and .data sections > for instructions that embed and variables that hold an absolute address > (I thought this was RELA?) > 2) pie emits a GOT such that there are no relocations as described in > 1), because all absolute addresses are indirected by GOT (just GOT > references are relocated) > Correct. And this works really well for shared libraries, where all text and data sections can be shared between processes, as they will not be modified by the loader. All locations targeted by relocations will be nicely lumped together in the GOT. However, for bare metal style programs, there is no sharing, and there is no advantage to lumping anything together. It is much better to use relative references where possible, and simply apply relocations wherever needed across the text and data sections, > If I understood the process right, but the term (GOT) is wrong, sorry, > that is what I gathered from the docs. :) > I have a x86 + PE background, so ARM + ELF is a bit of a learning curve..= . > The GOT is a special data structure used for implicit variable accesses, i.e., global vars used in the code. Statically initialized pointer variables are the other category, which are not code, and for which the same considerations do not apply, given that the right value simply needs to be stored in the variable before the program starts. > > 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. > > And this is not forced by whatever table -fpie uses, as per my > understanding above? > The selection of 'code model' as it is called is controlled by GCC's -mcmodel=3D argument, which defaults to 'small' on AArch64, regardless of whether you use PIC/PIE or not. > >>>> =E2=80=9CNow, StandaloneMmPkg has similar (self-)relocation code too= :https://github.com/tianocore/edk2/blob/17143c4837393d42c484b42d1789b85b2cf= f1aaf/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/AArch64/Standalone= MmCoreEntryPoint.c#L379-L386 > >>>> > >>>> Because I cannot find such elsewhere, I assume it must be for the sa= me ARM virtualised environment as above. > >>> No. > >>> > >>>> The binary it applies the Relocations to is documented to be the Sta= ndalone MM core, but in fact SecCore is located: > >>>> > >>>> https://github.com/tianocore/edk2/blob/17143c4837393d42c484b42d1789b= 85b2cff1aaf/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/AArch64/SetP= ermissions.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? > > That is what I meant to imply with the middle question (well, not > necessarily "lazy", for ARM there simply seems to not be any reason to > distinguish if the environments are fully separate), just wanted to make > sure I understand what the code does before modifying it. > > Thank you again! > > Best regards, > Marvin > > >>>> =E2=80=9CThis yields the following questions to me: > >>>> > >>>> 1) What even invokes Standalone MM on ARM? It is documented it is sp= awned 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 i= t 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 guarante= ed 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 o= f > >> 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. >