From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by mx.groups.io with SMTP id smtpd.web12.26536.1629130689182816153 for ; Mon, 16 Aug 2021 09:18:09 -0700 Authentication-Results: mx.groups.io; dkim=fail reason="body hash did not verify" header.i=@linux.microsoft.com header.s=default header.b=DRI3iGJ5; spf=pass (domain: linux.microsoft.com, ip: 13.77.154.182, mailfrom: mikuback@linux.microsoft.com) Received: from [10.0.0.120] (c-73-27-179-174.hsd1.fl.comcast.net [73.27.179.174]) by linux.microsoft.com (Postfix) with ESMTPSA id 51AD820C29E7; Mon, 16 Aug 2021 09:18:08 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 51AD820C29E7 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1629130688; bh=AhAlnFIK01Xyl2m/3+/gIwLP7JbDtUGEone8cQPa5Pw=; h=Subject:To:References:From:Date:In-Reply-To:From; b=DRI3iGJ5l1z3HFV68NYyXNrY5VVohXYVfYYrFVadW1sIZTVN2Y57XVkEt+Bq1v45O 8+FGTkKBdvrzGSdymDmX/ij0HrPY1OgvWRj8ZEoM5XHP+44S7vcQcjV/SDOkvUp69C O+UX38tV7mdvjkhf0A1aGJya+zC1mbmxiVP479sU= Subject: Re: [edk2-devel] SecCore evacuation in PeiCore? To: =?UTF-8?Q?Marvin_H=c3=a4user?= , devel@edk2.groups.io References: <82c95051-a508-997b-da05-21f8b2dc7c74@posteo.de> From: "Michael Kubacki" Message-ID: Date: Mon, 16 Aug 2021 12:18:06 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: <82c95051-a508-997b-da05-21f8b2dc7c74@posteo.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hi Marvin, Your understanding of SecMigrationPei is correct. It is not ideal as=20 it's an unfamiliar pattern that could give the false impression that it=20 is a universal SEC migration solution, which it is not. But if platforms=20 understand that any additional data published in SecCore must be=20 explicitly migrated (potentially via library extension to=20 SecMigrationPei), it can be used to serve the SEC post-memory migration=20 role. I assumed it was related to the reset vector due to the 16-bit=20 alignment. I think it would be great to have SecCore aligned properly if=20 possible. Thanks, Michael On 8/14/2021 8:29 AM, Marvin H=C3=A4user wrote: > 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=20 > has any references to the original SecCore at all, and the SecCore=20 > module basically just sits there in the ROM, and its exposed data is=20 > either 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=20 > be the issue with moving the ResetVector into a separate component,=20 > with its fixed position in FD (this is actually how UefiCpuPkg/VTF0=20 > works), and having SecCore aligned correctly? Not specifically to=20 > restore MigrateSecModulesInFv(), but as future-proofing to ensure=20 > expected outputs. In fact, I noticed because my new PE loader code was=20 > upset 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=20 >> an 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=20 >>> into the patch, or did the caller get lost somewhere? The=20 >>> description makes sense to me and I'm not experienced enough with=20 >>> the PeiCore control flow to tell whether the PEIM migration somehow=20 >>> covers SecCore implicitly. Also I noticed it only supports SecCore=20 >>> in a 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/9bedaec05b7b8ba9aee248361bb61a= 85a26726cb >>> >>> >>>=20 >>> >>