From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mout01.posteo.de (mout01.posteo.de [185.67.36.65]) by mx.groups.io with SMTP id smtpd.web11.35466.1629182481353934409 for ; Mon, 16 Aug 2021 23:41:22 -0700 Authentication-Results: mx.groups.io; dkim=fail reason="body hash did not verify" header.i=@posteo.de header.s=2017 header.b=kT9+0W7W; spf=pass (domain: posteo.de, ip: 185.67.36.65, mailfrom: mhaeuser@posteo.de) Received: from submission (posteo.de [89.146.220.130]) by mout01.posteo.de (Postfix) with ESMTPS id 88F16240029 for ; Tue, 17 Aug 2021 08:41:18 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1629182478; bh=uaYMUrcA2odZLfEx5jTk1nDVk4KmBIaFjip7kwqk4Vg=; h=Subject:To:From:Cc:Date:From; b=kT9+0W7WUxB/tC99MFZVgEMzw4MrOnSPng6bXZODVitPxxDGm9k27f1QTZYEm6v9E H4MecGi+CdATachQ+sqMd2JCa5LzxfnobENnJ3RK+IVClSxI1Sv6+M8Rjw7zk6Offy RcV6PWoPx4V7zOUCAu0IiwbLdzPNK6k9vmG069zmDk5CxsoArbV06eGpkxl1RaLgGD 4RjQuQkmIdRRVwvShtEoYiYEw61XuE6M6IKWQ2T6OH2FXputcd6M8aDW/RKxS3e7SJ +y5+/2pF8TGEU1yE9L4uDG8FeS6jI2xjrzvVuzJylOsJpxhPjf/IHHm2X2gKiS6hAb f1NX2nlUfwb+A== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4GphJF38NZz6tmP; Tue, 17 Aug 2021 08:41:17 +0200 (CEST) Subject: Re: [edk2-devel] SecCore evacuation in PeiCore? To: Michael Kubacki , devel@edk2.groups.io References: <82c95051-a508-997b-da05-21f8b2dc7c74@posteo.de> From: =?UTF-8?B?TWFydmluIEjDpHVzZXI=?= Cc: Bret Barkelew Message-ID: Date: Tue, 17 Aug 2021 06:41:17 +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 On 16/08/2021 18:18, Michael Kubacki wrote: > 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=20 > it is a universal SEC migration solution, which it is not. But if=20 > platforms understand that any additional data published in SecCore=20 > must be explicitly migrated (potentially via library extension to=20 > SecMigrationPei), it can be used to serve the SEC post-memory=20 > migration 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=20 > if possible. I could probably write a patch, but OVMF does not use this SecCore (and=20 still something is misaligned :) ), and I don't have any other platform.=20 Maybe I can ask Bret to test it as part of some PE loader validation in=20 the future. :) Would the old solution, which is being removed, be universal? Would it=20 be beneficial? I know that the ARM world does not use this SecCore=20 either, but I generally don't have a good idea about how their stuff works. Thanks! Best regards, Marvin > > 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=20 >> "SecCorePostMem", which either is loaded into permanent RAM directly=20 >> or is shadowed because it is a PEIM unlike SecCore - and it=20 >> republishes all public data, most especially PPIs, such that the=20 >> entire PEI stage no longer has any references to the original SecCore=20 >> at all, and the SecCore module basically just sits there in the ROM,=20 >> and its exposed data is either discarded or orphaned? Is that about=20 >> 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=20 >> was 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.=20 >>> I don't see where this was resolved other than the calls being=20 >>> removed later in the series. SecCore migration would not occur=20 >>> implicitly in the PeiCore flow but there is functionality for SEC=20 >>> data migration in 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/9bedaec05b7b8ba9aee248361bb61= a85a26726cb >>>> >>>> >>>>=20 >>>> >>> >