public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Marvin Häuser" <mhaeuser@posteo.de>
To: Michael Kubacki <mikuback@linux.microsoft.com>, devel@edk2.groups.io
Subject: Re: [edk2-devel] SecCore evacuation in PeiCore?
Date: Sat, 14 Aug 2021 12:29:34 +0000	[thread overview]
Message-ID: <82c95051-a508-997b-da05-21f8b2dc7c74@posteo.de> (raw)
In-Reply-To: <bcfad399-0d22-2b51-2669-2bbbdf0819ec@linux.microsoft.com>

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 
right. Can I think of "SecMigrationPei" as a sort of "SecCorePostMem", 
which either is loaded into permanent RAM directly or is shadowed 
because it is a PEIM unlike SecCore - and it republishes all public 
data, most especially PPIs, such that the entire PEI stage no longer has 
any references to the original SecCore at all, and the SecCore module 
basically just sits there in the ROM, and its exposed data is either 
discarded or orphaned? Is that about right?

I think I hit the alignment issue of SecCore too, but only for X64 
builds (likely just because the size happens to be lucky for IA32) of 
OVMF. Pretty much sure it's just ResetVector positioning. What would be 
the issue with moving the ResetVector into a separate component, with 
its fixed position in FD (this is actually how UefiCpuPkg/VTF0 works), 
and having SecCore aligned correctly? Not specifically to restore 
MigrateSecModulesInFv(), but as future-proofing to ensure expected 
outputs. In fact, I noticed because my new PE loader code 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. 
> The function was called from EvacuateTempRam() in the initial set of 
> patches:
> [PATCH 1/6] MdeModulePkg/PeiCore: Enable T-RAM evacuation in PeiCore 
> (CVE-2019-11098) (groups.io) 
> <https://edk2.groups.io/g/devel/message/61823>
>
> I was not involved in the patch series on the mailing list (job role 
> change at the time) but as a comment in that patch notes, there was an 
> inconsistency observed in PE32 section alignment in SEC modules. I 
> don't see where this was resolved other than the calls being removed 
> later in the series. SecCore migration would not occur implicitly in 
> the PeiCore flow but there is functionality for SEC data migration in 
> UefiCpuPkg/SecMigrationPei.
>
> Based on what I see now, I'd be happy to send a patch to remove 
> MigrateSecModulesInFv().
>
> Thanks,
> Michael
>
> On 8/7/2021 2:54 PM, Marvin Häuser wrote:
>> Good day everyone,
>> Good day Michael,
>>
>> The commit that introduced T-RAM evacuation [1] also introduced the 
>> function "MigrateSecModulesInFv()". It also is explicitly mentioned 
>> as part of the control flow in the commit message. As far as I can 
>> see, since then till today this function has never been called 
>> anywhere. Was this some draft function that accidentally made it into 
>> the patch, or did the caller get lost somewhere? The description 
>> makes sense to me and I'm not experienced enough with the PeiCore 
>> control flow to tell whether the PEIM migration somehow covers 
>> SecCore implicitly. Also I noticed it only supports SecCore in a 
>> PE/COFF section, not a TE section. Is there a rationale for that?
>>
>> Thank you for your time!
>>
>> Best regards,
>> Marvin
>>
>>
>> [1] 
>> https://github.com/tianocore/edk2/commit/9bedaec05b7b8ba9aee248361bb61a85a26726cb
>>
>>
>> 
>>
>


  reply	other threads:[~2021-08-14 12:29 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-07 18:54 SecCore evacuation in PeiCore? Marvin Häuser
2021-08-13 16:51 ` [edk2-devel] " Michael Kubacki
2021-08-14 12:29   ` Marvin Häuser [this message]
2021-08-16 16:18     ` Michael Kubacki
2021-08-17  6:41       ` Marvin Häuser
2021-08-17 16:16         ` Michael Kubacki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=82c95051-a508-997b-da05-21f8b2dc7c74@posteo.de \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox