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.web08.9152.1626966871696960199 for ; Thu, 22 Jul 2021 08:14:31 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=DSgn6lWc; spf=pass (domain: kernel.org, ip: 198.145.29.99, mailfrom: ardb@kernel.org) Received: by mail.kernel.org (Postfix) with ESMTPSA id 00A0260FDA for ; Thu, 22 Jul 2021 15:14:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1626966871; bh=BC3HsgfuhsZvFkUXb3vWqMv0OXRvsEuxBuriJ5NW1j0=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=DSgn6lWcI1UhUg7WB/bqdURK/9kkiJQWHNUVp+Me1rK0+YUKmATfd8Ef/hGB07WpE e5DFqQpo13zX7Od9mbw0B/V6gBDrgdVzl3xc/bt/eVPVsfaUkLGs8vRrEcbk2Pyzbo 9vPtCzf16dwxST7wsn0jmyWbEIIWcQUVO6GunyPtlxCZClctL2L2cGn7oK82XP/yVR TKgqnXU//jTJqw0vjVIocCVSxX1fUEB7cejaH7V15XcLHWdsk14xEeHLHqnJdtux+H NgiXS4UfgLjO8iYFu7R8sZn6HMWNmK6VInuTc0LYK2IF/OTK4tbGNCHN4yRQbDlUn0 YtaWQrrfkvvkg== Received: by mail-ot1-f50.google.com with SMTP id 59-20020a9d0ac10000b0290462f0ab0800so5557720otq.11 for ; Thu, 22 Jul 2021 08:14:30 -0700 (PDT) X-Gm-Message-State: AOAM531sxmOiPEz9XIfrq+Wb8v/Cd1xLuaUgTVrLmPaQQsa2jU3dDIsT RoATSpodLLjsrzBU+y/5C3bJQDHjo/0ynd2d8yA= X-Google-Smtp-Source: ABdhPJxZYTo8vojRIkfZazMb3T83VpDBiP6zyx1ARvl33sD5efXWa80OaJIPI8neEEue1kQ5qP40A/aYwn6gWifN6LQ= X-Received: by 2002:a05:6830:2316:: with SMTP id u22mr172089ote.90.1626966870379; Thu, 22 Jul 2021 08:14:30 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Ard Biesheuvel" Date: Thu, 22 Jul 2021 17:14:17 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: ArmVirt and Self-Updating Code To: Bret Barkelew Cc: Thomas Abraham , "Ard Biesheuvel (TianoCore)" , "Lindholm, Leif" , Laszlo Ersek , =?UTF-8?Q?Marvin_H=C3=A4user?= , Sami Mujawar , "devel@edk2.groups.io" , nd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 22 Jul 2021 at 16:54, Bret Barkelew w= rote: > > 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 Ers= ek; 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) <= ardb+tianocore@kernel.org>; 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 l= ittle beyond my ken=E2=80=A6 > > > > =E2=80=9CThere is self-relocating code in ArmVirtPkg: > > https://github.com/tianocore/edk2/blob/17143c4837393d42c484b42d1789b85b2c= ff1aaf/ArmVirtPkg/PrePi/PrePi.c#L133-L165 > > According to comments in the ASM, it seems like this is for Linux-based R= AM 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-re= location 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. > > > =E2=80=9CNow, StandaloneMmPkg has similar (self-)relocation code too: htt= ps://github.com/tianocore/edk2/blob/17143c4837393d42c484b42d1789b85b2cff1aa= f/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/AArch64/StandaloneMmCo= reEntryPoint.c#L379-L386 > > Because I cannot find such elsewhere, I assume it must be for the same AR= M virtualised environment as above. No. > The binary it applies the Relocations to is documented to be the Standalo= ne MM core, but in fact SecCore is located: > > https://github.com/tianocore/edk2/blob/17143c4837393d42c484b42d1789b85b2c= ff1aaf/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/AArch64/SetPermis= sions.c#L131-L158 > > > > =E2=80=9CThis yields the following questions to me: > > 1) What even invokes Standalone MM on ARM? It is documented it is spawned= 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 Standalo= ne 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. > 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. > > > Hoping that one of you could get me closer to an answer for him. Also hap= py to take this to the greater mailing list, but thought I=E2=80=99d avoid = churn. > > > > Thanks in advance! > > - Bret > > > >