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.

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



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#104290): https://edk2.groups.io/g/devel/message/104290
Mute This Topic: https://groups.io/mt/98771393/1787277
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org]
-=-=-=-=-=-=-=-=-=-=-=-

On 5/8/23 23:31, 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 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.
> 
> 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(-)
> 

I'm not subscribed to the list, so I don't have a copy of patch#1. I've
checked patch#1 at this URL:

https://listman.redhat.com/archives/edk2-devel-archive/2023-May/063591.html

and I'll comment on it using the cover letter:

I really like that patch, with one stylistic exception: in edk2,
explicit FALSE and TRUE comparisons are not desired. So I suggest:

  ASSERT (!GetInterruptState ());

Twice.

In fact, I *think* that if you run uncrustify with the edk2 config on
the patch, then it will rewrite that code.

Uncrustify normally only complains in CI on github, but you can run it
manually too, after each commit:

(1) Clone and build uncrustify:

https://projectmu@dev.azure.com/projectmu/Uncrustify/_git/Uncrustify

(2) After each commit, preferably when your working tree *and* index are
clean, run uncrustify in the edk2 project root, with the following flags:

  -c .pytool/Plugin/UncrustifyCheck/uncrustify.cfg \
  --replace \
  --no-backup \
  --if-changed

The file list can be passed in via stdin ("-F -") or on the uncrustify
command line.

The "file list" is generally the list of *.c and *.h files modified by
the particular commit. Just dumping the entire file list modified by a
commit to uncrustify is not good: uncrustify will happily garble (for
example) *.inf files, and then it will also crash with SEGV.

Thank you!
Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#104356): https://edk2.groups.io/g/devel/message/104356
Mute This Topic: https://groups.io/mt/98771393/1787277
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/leave/3901457/1787277/102458076/xyzzy [importer@patchew.org]
-=-=-=-=-=-=-=-=-=-=-=-

On 09/05/2023 09:43, Laszlo Ersek wrote:
> I'm not subscribed to the list, so I don't have a copy of patch#1. I've
> checked patch#1 at this URL:
> 
> https://listman.redhat.com/archives/edk2-devel-archive/2023-May/063591.html
> 
> and I'll comment on it using the cover letter:
> 
> I really like that patch, with one stylistic exception: in edk2,
> explicit FALSE and TRUE comparisons are not desired. So I suggest:
> 
>    ASSERT (!GetInterruptState ());
> 
> Twice.
> 
> In fact, I *think* that if you run uncrustify with the edk2 config on
> the patch, then it will rewrite that code.

I built and ran uncrustify with the edk2 config but it did not modify 
the code.  (I did check that it would fix other deliberate errors such 
as extra whitespace, so I don't think this was an error in my setup.)

I will send through v2 with the explicit "== FALSE" still present, for 
consistency with the rest of the code in that file.  (I think I vaguely 
remember someone asking me to add the explicit comparisons when I first 
submitted the code.)  I'm happy for there to be a follow up patch to 
change the coding style to remove all of the explicit boolean 
comparisons, if that is what is wanted.

Thanks,

Michael



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#104365): https://edk2.groups.io/g/devel/message/104365
Mute This Topic: https://groups.io/mt/98771393/1787277
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org]
-=-=-=-=-=-=-=-=-=-=-=-

On 5/9/23 14:08, Michael Brown wrote:
> On 09/05/2023 09:43, Laszlo Ersek wrote:
>> I'm not subscribed to the list, so I don't have a copy of patch#1. I've
>> checked patch#1 at this URL:
>>
>> https://listman.redhat.com/archives/edk2-devel-archive/2023-May/063591.html
>>
>> and I'll comment on it using the cover letter:
>>
>> I really like that patch, with one stylistic exception: in edk2,
>> explicit FALSE and TRUE comparisons are not desired. So I suggest:
>>
>>    ASSERT (!GetInterruptState ());
>>
>> Twice.
>>
>> In fact, I *think* that if you run uncrustify with the edk2 config on
>> the patch, then it will rewrite that code.
> 
> I built and ran uncrustify with the edk2 config but it did not modify
> the code.  (I did check that it would fix other deliberate errors such
> as extra whitespace, so I don't think this was an error in my setup.)
> 
> I will send through v2 with the explicit "== FALSE" still present, for
> consistency with the rest of the code in that file.  (I think I vaguely
> remember someone asking me to add the explicit comparisons when I first
> submitted the code.)

Wow, I totally missed the preexistent comparisons. You are right to stay
consistent.

(I do disagree with the preexistent comparisons as well, but that's
indeed a different discussion.)

Thanks!
Laszlo

> I'm happy for there to be a follow up patch to
> change the coding style to remove all of the explicit boolean
> comparisons, if that is what is wanted.
> 
> Thanks,
> 
> Michael
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#104369): https://edk2.groups.io/g/devel/message/104369
Mute This Topic: https://groups.io/mt/98771393/1787277
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/leave/3901457/1787277/102458076/xyzzy [importer@patchew.org]
-=-=-=-=-=-=-=-=-=-=-=-

On Mon, May 08, 2023 at 09:31:23PM +0000, 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 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.
> 
> 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

Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>

take care,
  Gerd



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#104336): https://edk2.groups.io/g/devel/message/104336
Mute This Topic: https://groups.io/mt/98771393/1787277
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org]
-=-=-=-=-=-=-=-=-=-=-=-