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.web12.48872.1628944178892437087 for ; Sat, 14 Aug 2021 05:29:39 -0700 Authentication-Results: mx.groups.io; dkim=fail reason="body hash did not verify" header.i=@posteo.de header.s=2017 header.b=VE/LeYwq; 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 CC694240101 for ; Sat, 14 Aug 2021 14:29:35 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1628944175; bh=UovWILSCUFIj3SW1+DS3gh6zKgef3HVPVnHzWgVWonU=; h=Subject:To:From:Date:From; b=VE/LeYwqhncrMWYAgQ1bBW/X5xjVXv0xAgdC8rnSiD9mP76UO8OvtIGdgnuh+penB oEckGTojjVGFGPIJ09Zp2b/IM9OV0dNyoHJMs/rbGmv3yDCSmweHGYbQEEngRRU5+c N65EgxflL4vWdU+LsnjyW2xN0J9jzkFNX38dS7NqN3ZZciOPupVSHITNg4EhqhIB2t QN4ts8tWQuHkhdtxprHBnjIwQMBtX2ANwCjEhULS9PkBjAYSHbjvnwk4o49RPZWf0D /ql9HY0YAhDveaESb7WODafoc6TZFA7dubtKJQadQoPFD/zOzZ4cX4dzHgli6/EQ5e 7Gt/9HaSEQgPg== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4Gn09W1Bvdz6tmD; Sat, 14 Aug 2021 14:29:34 +0200 (CEST) Subject: Re: [edk2-devel] SecCore evacuation in PeiCore? To: Michael Kubacki , devel@edk2.groups.io References: From: =?UTF-8?B?TWFydmluIEjDpHVzZXI=?= Message-ID: <82c95051-a508-997b-da05-21f8b2dc7c74@posteo.de> Date: Sat, 14 Aug 2021 12:29:34 +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 Hey Michael, Thank you for your response! It was actually quicker than I imagined. :) I think I understand, but please let me try to get this absolutely=20 right. Can I think of "SecMigrationPei" as a sort of "SecCorePostMem",=20 which either is loaded into permanent RAM directly or is shadowed=20 because it is a PEIM unlike SecCore - and it republishes all public=20 data, most especially PPIs, such that the entire PEI stage no longer has=20 any references to the original SecCore at all, and the SecCore module=20 basically just sits there in the ROM, and its exposed data is either=20 discarded or orphaned? Is that about right? I think I hit the alignment issue of SecCore too, but only for X64=20 builds (likely just because the size happens to be lucky for IA32) of=20 OVMF. Pretty much sure it's just ResetVector positioning. What would be=20 the issue with moving the ResetVector into a separate component, with=20 its fixed position in FD (this is actually how UefiCpuPkg/VTF0 works),=20 and having SecCore aligned correctly? Not specifically to restore=20 MigrateSecModulesInFv(), but as future-proofing to ensure expected=20 outputs. In fact, I noticed because my new PE loader code was upset=20 about the unaligned XIP load address. Also thanks for your patch! Best regards, Marvin On 13/08/2021 18:51, Michael Kubacki wrote: > Hi Marvin, > > I apologize for the delayed response, I missed this message earlier.=20 > The function was called from EvacuateTempRam() in the initial set of=20 > patches: > [PATCH 1/6] MdeModulePkg/PeiCore: Enable T-RAM evacuation in PeiCore=20 > (CVE-2019-11098) (groups.io)=20 > > > I was not involved in the patch series on the mailing list (job role=20 > change at the time) but as a comment in that patch notes, there was an=20 > inconsistency observed in PE32 section alignment in SEC modules. I=20 > don't see where this was resolved other than the calls being removed=20 > later in the series. SecCore migration would not occur implicitly in=20 > the PeiCore flow but there is functionality for SEC data migration in=20 > UefiCpuPkg/SecMigrationPei. > > Based on what I see now, I'd be happy to send a patch to remove=20 > MigrateSecModulesInFv(). > > Thanks, > Michael > > On 8/7/2021 2:54 PM, Marvin H=C3=A4user wrote: >> Good day everyone, >> Good day Michael, >> >> The commit that introduced T-RAM evacuation [1] also introduced the=20 >> function "MigrateSecModulesInFv()". It also is explicitly mentioned=20 >> as part of the control flow in the commit message. As far as I can=20 >> see, since then till today this function has never been called=20 >> anywhere. Was this some draft function that accidentally made it into=20 >> the patch, or did the caller get lost somewhere? The description=20 >> makes sense to me and I'm not experienced enough with the PeiCore=20 >> control flow to tell whether the PEIM migration somehow covers=20 >> SecCore implicitly. Also I noticed it only supports SecCore in a=20 >> PE/COFF section, not a TE section. Is there a rationale for that? >> >> Thank you for your time! >> >> Best regards, >> Marvin >> >> >> [1]=20 >> https://github.com/tianocore/edk2/commit/9bedaec05b7b8ba9aee248361bb61a8= 5a26726cb >> >> >>=20 >> >