[PATCH v2 0/2] OvmfPkg: Relax assertion that interrupts do not occur at TPL_HIGH_LEVEL

[PATCH v2 0/2] OvmfPkg: Relax assertion that interrupts do not occur at TPL_HIGH_LEVEL

[Michael Brown]

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 actually prevents a UEFI application from calling
gBS->RaiseTPL(TPL_HIGH_LEVEL) and then 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 UEFI applications such as these versions
of the Microsoft Windows bootloader to continue to function.

Ref: https://bugzilla.redhat.com/show_bug.cgi?id=2189136
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Oliver Steffen <osteffen@redhat.com>
Cc: Pawel Polawski <ppolawsk@redhat.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>

Michael Brown (2):
  OvmfPkg: Clarify invariants for NestedInterruptTplLib
  OvmfPkg: Relax assertion that interrupts do not occur at
    TPL_HIGH_LEVEL

 OvmfPkg/Library/NestedInterruptTplLib/Tpl.c | 31 +++++++++++++++++----
 1 file changed, 26 insertions(+), 5 deletions(-)

-- 
2.39.0

[PATCH v2 1/2] OvmfPkg: Clarify invariants for NestedInterruptTplLib

[Michael Brown]

NestedInterruptTplLib relies on CPU interrupts being disabled to
guarantee exclusive (and hence atomic) access to the shared state in
IsrState.  Nothing in the calling interrupt handler should have
re-enabled interrupts before calling NestedInterruptRestoreTPL(), and
the loop in NestedInterruptRestoreTPL() itself maintains the invariant
that interrupts are disabled at the start of each iteration.

Add assertions to clarify this invariant, and expand the comments
around the calls to RestoreTPL() and DisableInterrupts() to clarify
the expectations around enabling and disabling interrupts.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
---
 OvmfPkg/Library/NestedInterruptTplLib/Tpl.c | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/OvmfPkg/Library/NestedInterruptTplLib/Tpl.c b/OvmfPkg/Library/NestedInterruptTplLib/Tpl.c
index e19d98878eb7..e921a09c5599 100644
--- a/OvmfPkg/Library/NestedInterruptTplLib/Tpl.c
+++ b/OvmfPkg/Library/NestedInterruptTplLib/Tpl.c
@@ -104,6 +104,7 @@ NestedInterruptRestoreTPL (
   // defer our call to RestoreTPL() to the in-progress outer instance
   // of the same interrupt handler.
   //
+  ASSERT (GetInterruptState () == FALSE);
   if (InterruptedTPL == IsrState->InProgressRestoreTPL) {
     //
     // Trigger outer instance of this interrupt handler to perform the
@@ -153,6 +154,7 @@ NestedInterruptRestoreTPL (
     //
     // Check shared state loop invariants.
     //
+    ASSERT (GetInterruptState () == FALSE);
     ASSERT (IsrState->InProgressRestoreTPL < InterruptedTPL);
     ASSERT (IsrState->DeferredRestoreTPL == FALSE);
 
@@ -167,13 +169,17 @@ NestedInterruptRestoreTPL (
 
     //
     // Call RestoreTPL() to allow event notifications to be
-    // dispatched.  This will implicitly re-enable interrupts.
+    // dispatched.  This will implicitly re-enable interrupts (if
+    // InterruptedTPL is below TPL_HIGH_LEVEL), even though we are
+    // still inside the interrupt handler.
     //
     gBS->RestoreTPL (InterruptedTPL);
 
     //
     // Re-disable interrupts after the call to RestoreTPL() to ensure
-    // that we have exclusive access to the shared state.
+    // that we have exclusive access to the shared state.  Interrupts
+    // will be re-enabled by the IRET or equivalent instruction when
+    // we subsequently return from the interrupt handler.
     //
     DisableInterrupts ();
 
-- 
2.39.0

[PATCH v2 2/2] OvmfPkg: Relax assertion that interrupts do not occur at TPL_HIGH_LEVEL

[Michael Brown]

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 actually prevents a UEFI application from calling
gBS->RaiseTPL(TPL_HIGH_LEVEL) and then 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 UEFI applications such as these versions
of the Microsoft Windows bootloader to continue to function.

Debugged-by: Gerd Hoffmann <kraxel@redhat.com>
Debugged-by: Laszlo Ersek <lersek@redhat.com>
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=2189136
Signed-off-by: Michael Brown <mcb30@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..d56c12a44529 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 actually prevents a UEFI application from
+  // invalidly calling gBS->RaiseTPL(TPL_HIGH_LEVEL) and then
+  // 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, "ERROR: Interrupts enabled at TPL_HIGH_LEVEL!\n"));
+  }
 
   return InterruptedTPL;
 }
-- 
2.39.0

Re: [PATCH v2 0/2] OvmfPkg: Relax assertion that interrupts do not occur at TPL_HIGH_LEVEL

[Laszlo Ersek]

On 5/9/23 14:09, Michael Brown wrote:
> 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 actually prevents a UEFI application from calling
> gBS->RaiseTPL(TPL_HIGH_LEVEL) and then 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 UEFI applications such as these versions
> of the Microsoft Windows bootloader to continue to function.
> 
> Ref: https://bugzilla.redhat.com/show_bug.cgi?id=2189136
> Cc: Laszlo Ersek <lersek@redhat.com>
> Cc: Gerd Hoffmann <kraxel@redhat.com>
> Cc: Oliver Steffen <osteffen@redhat.com>
> Cc: Pawel Polawski <ppolawsk@redhat.com>
> Cc: Jiewen Yao <jiewen.yao@intel.com>
> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
> Cc: Jordan Justen <jordan.l.justen@intel.com>
> 
> Michael Brown (2):
>   OvmfPkg: Clarify invariants for NestedInterruptTplLib
>   OvmfPkg: Relax assertion that interrupts do not occur at
>     TPL_HIGH_LEVEL
> 
>  OvmfPkg/Library/NestedInterruptTplLib/Tpl.c | 31 +++++++++++++++++----
>  1 file changed, 26 insertions(+), 5 deletions(-)
> 

series
Acked-by: Laszlo Ersek <lersek@redhat.com>

Many thanks,
Laszlo

Re: [edk2-devel] [PATCH v2 0/2] OvmfPkg: Relax assertion that interrupts do not occur at TPL_HIGH_LEVEL

[Michael Brown]

On 09/05/2023 14:31, Laszlo Ersek wrote:
> On 5/9/23 14:09, Michael Brown wrote:
>> 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 actually prevents a UEFI application from calling
>> gBS->RaiseTPL(TPL_HIGH_LEVEL) and then 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 UEFI applications such as these versions
>> of the Microsoft Windows bootloader to continue to function.
>>
>> Ref: https://bugzilla.redhat.com/show_bug.cgi?id=2189136
>> Cc: Laszlo Ersek <lersek@redhat.com>
>> Cc: Gerd Hoffmann <kraxel@redhat.com>
>> Cc: Oliver Steffen <osteffen@redhat.com>
>> Cc: Pawel Polawski <ppolawsk@redhat.com>
>> Cc: Jiewen Yao <jiewen.yao@intel.com>
>> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
>> Cc: Jordan Justen <jordan.l.justen@intel.com>
>>
>> Michael Brown (2):
>>    OvmfPkg: Clarify invariants for NestedInterruptTplLib
>>    OvmfPkg: Relax assertion that interrupts do not occur at
>>      TPL_HIGH_LEVEL
>>
>>   OvmfPkg/Library/NestedInterruptTplLib/Tpl.c | 31 +++++++++++++++++----
>>   1 file changed, 26 insertions(+), 5 deletions(-)
>>
> 
> series
> Acked-by: Laszlo Ersek <lersek@redhat.com>

Thank you!

Gerd: are you happy for your Reviewed-by to stand, since the only 
changes since v1 were to comment wording?  (My apologies for forgetting 
to include a v2 description in the cover letter.)

Thanks,

Michael

Re: [edk2-devel] [PATCH v2 0/2] OvmfPkg: Relax assertion that interrupts do not occur at TPL_HIGH_LEVEL

[Ard Biesheuvel]

(cc Liming)

On Tue, 9 May 2023 at 16:23, Michael Brown <mcb30@ipxe.org> wrote:
>
> On 09/05/2023 14:31, Laszlo Ersek wrote:
> > On 5/9/23 14:09, Michael Brown wrote:
> >> 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 actually prevents a UEFI application from calling
> >> gBS->RaiseTPL(TPL_HIGH_LEVEL) and then 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 UEFI applications such as these versions
> >> of the Microsoft Windows bootloader to continue to function.
> >>
> >> Ref: https://bugzilla.redhat.com/show_bug.cgi?id=2189136
> >> Cc: Laszlo Ersek <lersek@redhat.com>
> >> Cc: Gerd Hoffmann <kraxel@redhat.com>
> >> Cc: Oliver Steffen <osteffen@redhat.com>
> >> Cc: Pawel Polawski <ppolawsk@redhat.com>
> >> Cc: Jiewen Yao <jiewen.yao@intel.com>
> >> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
> >> Cc: Jordan Justen <jordan.l.justen@intel.com>
> >>
> >> Michael Brown (2):
> >>    OvmfPkg: Clarify invariants for NestedInterruptTplLib
> >>    OvmfPkg: Relax assertion that interrupts do not occur at
> >>      TPL_HIGH_LEVEL
> >>
> >>   OvmfPkg/Library/NestedInterruptTplLib/Tpl.c | 31 +++++++++++++++++----
> >>   1 file changed, 26 insertions(+), 5 deletions(-)
> >>
> >
> > series
> > Acked-by: Laszlo Ersek <lersek@redhat.com>
>
> Thank you!
>
> Gerd: are you happy for your Reviewed-by to stand, since the only
> changes since v1 were to comment wording?

I'll assume that it stands if that was the only difference.

I've queued this up now - thanks all for the hard work.

(Note to Liming - this is definitely a candidate for the stable tag,
see the bugzilla link for details)


>  (My apologies for forgetting
> to include a v2 description in the cover letter.)
>
> Thanks,
>
> Michael
>
>

Re: [edk2-devel] [PATCH v2 0/2] OvmfPkg: Relax assertion that interrupts do not occur at TPL_HIGH_LEVEL

[Ard Biesheuvel]

On Tue, 9 May 2023 at 23:49, Ard Biesheuvel <ardb@kernel.org> wrote:
>
> (cc Liming)
>
> On Tue, 9 May 2023 at 16:23, Michael Brown <mcb30@ipxe.org> wrote:
> >
> > On 09/05/2023 14:31, Laszlo Ersek wrote:
> > > On 5/9/23 14:09, Michael Brown wrote:
> > >> 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 actually prevents a UEFI application from calling
> > >> gBS->RaiseTPL(TPL_HIGH_LEVEL) and then 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 UEFI applications such as these versions
> > >> of the Microsoft Windows bootloader to continue to function.
> > >>
> > >> Ref: https://bugzilla.redhat.com/show_bug.cgi?id=2189136
> > >> Cc: Laszlo Ersek <lersek@redhat.com>
> > >> Cc: Gerd Hoffmann <kraxel@redhat.com>
> > >> Cc: Oliver Steffen <osteffen@redhat.com>
> > >> Cc: Pawel Polawski <ppolawsk@redhat.com>
> > >> Cc: Jiewen Yao <jiewen.yao@intel.com>
> > >> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
> > >> Cc: Jordan Justen <jordan.l.justen@intel.com>
> > >>
> > >> Michael Brown (2):
> > >>    OvmfPkg: Clarify invariants for NestedInterruptTplLib
> > >>    OvmfPkg: Relax assertion that interrupts do not occur at
> > >>      TPL_HIGH_LEVEL
> > >>
> > >>   OvmfPkg/Library/NestedInterruptTplLib/Tpl.c | 31 +++++++++++++++++----
> > >>   1 file changed, 26 insertions(+), 5 deletions(-)
> > >>
> > >
> > > series
> > > Acked-by: Laszlo Ersek <lersek@redhat.com>
> >
> > Thank you!
> >
> > Gerd: are you happy for your Reviewed-by to stand, since the only
> > changes since v1 were to comment wording?
>
> I'll assume that it stands if that was the only difference.
>
> I've queued this up now - thanks all for the hard work.
>
> (Note to Liming - this is definitely a candidate for the stable tag,
> see the bugzilla link for details)
>

Merged as #4371