At TPL_HIGH_LEVEL, CPU interrupts are disabled (as per the UEFI specification) and so we should never encounter a situation in which an interrupt occurs at TPL_HIGH_LEVEL. The specification also restricts usage of TPL_HIGH_LEVEL to the firmware itself.
However, nothing prevents a rogue UEFI application from illegally calling gBS->RaiseTPL(TPL_HIGH_LEVEL) and then deliberately violating the invariant by enabling interrupts via the STI or equivalent instruction. Some versions of the Microsoft Windows bootloader are known to do this. NestedInterruptTplLib maintains the invariant that interrupts are disabled at TPL_HIGH_LEVEL (even when performing the dark art of deliberately manipulating the stack so that IRET will return with interrupts still disabled), but does not itself rely on external code maintaining this invariant. Relax the assertion that the interrupted TPL is below TPL_HIGH_LEVEL to an error message, to allow rogue UEFI applications such as the Microsoft Windows bootloader to continue to function. Debugged-by: Gerd Hoffmann <kra...@redhat.com> Debugged-by: Laszlo Ersek <ler...@redhat.com> Ref: https://bugzilla.redhat.com/show_bug.cgi?id=2189136 Signed-off-by: Michael Brown <mc...@ipxe.org> --- OvmfPkg/Library/NestedInterruptTplLib/Tpl.c | 21 ++++++++++++++++++--- 1 file changed, 18 insertions(+), 3 deletions(-) diff --git a/OvmfPkg/Library/NestedInterruptTplLib/Tpl.c b/OvmfPkg/Library/NestedInterruptTplLib/Tpl.c index e921a09c5599..a91f2d3cb8c7 100644 --- a/OvmfPkg/Library/NestedInterruptTplLib/Tpl.c +++ b/OvmfPkg/Library/NestedInterruptTplLib/Tpl.c @@ -34,12 +34,27 @@ NestedInterruptRaiseTPL ( // // Raise TPL and assert that we were called from within an interrupt - // handler (i.e. with TPL below TPL_HIGH_LEVEL but with interrupts - // disabled). + // handler (i.e. with interrupts already disabled before raising the + // TPL). // ASSERT (GetInterruptState () == FALSE); InterruptedTPL = gBS->RaiseTPL (TPL_HIGH_LEVEL); - ASSERT (InterruptedTPL < TPL_HIGH_LEVEL); + + // + // At TPL_HIGH_LEVEL, CPU interrupts are disabled (as per the UEFI + // specification) and so we should never encounter a situation in + // which InterruptedTPL==TPL_HIGH_LEVEL. The specification also + // restricts usage of TPL_HIGH_LEVEL to the firmware itself. + // + // However, nothing prevents a rogue UEFI application from illegally + // calling gBS->RaiseTPL(TPL_HIGH_LEVEL) and then deliberately + // violating the invariant by enabling interrupts via the STI or + // equivalent instruction. Some versions of the Microsoft Windows + // bootloader are known to do this. + // + if (InterruptedTPL >= TPL_HIGH_LEVEL) { + DEBUG ((DEBUG_ERROR, "Illegal interrupt at TPL_HIGH_LEVEL!\n")); + } return InterruptedTPL; } -- 2.39.0 -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#104292): https://edk2.groups.io/g/devel/message/104292 Mute This Topic: https://groups.io/mt/98771399/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-