<p></p>
<p><a class="user-mention" data-hovercard-type="user" data-hovercard-url="/users/huanghe4/hovercard" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/huanghe4">@huanghe4</a> The expected mechanism (as documented in <a href="https://github.com/ipxe/ipxe/commit/c89a446cf09f30a121ae21d91f4a1aa071044084#diff-8abaf825db412e28b0c57b0f8947ed23">[efi] Run at TPL_CALLBACK to protect against UEFI timers</a> is that iPXE code runs at TPL_CALLBACK almost all of the time, in order to overcome fundamental design flaws in the UEFI specification.</p>
<p>iPXE will record the TPL at which it was entered and will restore this TPL before exiting.  This applies to all externally callable entry points, such as the SNP API (see e.g. the matched RaiseTPL/RestoreTPL calls in <code>efi_snp_get_status()</code>).</p>
<p>This also applies to the overall code path from initial invocation through to ExitBootServices, although this is less immediately obvious due to the exchange of responsibilities between different UEFI components.  The expected sequence of events is:</p>
<ul>
<li>An application-level entry point such as <code>_efi_start()</code> or <code>efi_snp_load_file()</code> (as opposed to an API-level entry point such as <code>efi_snp_get_status()</code>) will call <code>efi_snp_claim()</code> to claim exclusive ownership of the network devices for iPXE (and so to prevent packet loss due to other UEFI code attempting to poll the network).</li>
<li>This call to <code>efi_snp_claim()</code> will record the original TPL in <code>efi_snp_old_tpl</code> and will raise to TPL_CALLBACK.</li>
<li>Before executing an image (such as an OS kernel), iPXE will call <code>efi_snp_release()</code></li>
<li>This call to <code>efi_snp_release()</code> will restore the original TPL as recorded in <code>efi_snp_old_tpl</code></li>
<li>iPXE then invokes the OS kernel via <code>StartImage()</code>.  At this point, the TPL is whatever TPL was recorded when iPXE was started, which should be TPL_APPLICATION.</li>
<li>The OS kernel is responsible for calling <code>ExitBootServices()</code></li>
</ul>
<p>I have added debug code to iPXE to dump the TPL prior to calling <code>StartImage()</code> and (via the <code>efi_wrap</code> mechanism) to dump the TPL at the point that the OS kernel invokes <code>ExitBootServices()</code>.  I have tested with both an iPXE EFI ROM and with a chainloaded <code>snponly.efi</code>.  In both cases and at both debug points the TPL was TPL_APPLICATION, as expected.</p>
<p>Is it possible that the AMI BIOS is erroneously starting iPXE at TPL_CALLBACK, thereby causing <code>efi_snp_old_tpl</code> to end up containing TPL_CALLBACK rather than TPL_APPLICATION?</p>
<p>Michael</p>

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br />You are receiving this because you commented.<br />Reply to this email directly, <a href="https://github.com/ipxe/ipxe/pull/113#issuecomment-651721586">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AAFNGVHDP7O3ZOZQHEZLMKLRZHAUXANCNFSM4NMSFYRA">unsubscribe</a>.<img src="https://github.com/notifications/beacon/AAFNGVDQZ4YDYG5ULWN7VZTRZHAUXA5CNFSM4NMSFYRKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOE3MHW4Q.gif" height="1" width="1" alt="" /></p>
<script type="application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/ipxe/ipxe/pull/113#issuecomment-651721586",
"url": "https://github.com/ipxe/ipxe/pull/113#issuecomment-651721586",
"name": "View Pull Request"
},
"description": "View this Pull Request on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>