From: "Michael Brown" <mcb30@ipxe.org>
To: devel@edk2.groups.io, lersek@redhat.com
Cc: Ray Ni <ray.ni@intel.com>, Gerd Hoffmann <kraxel@redhat.com>
Subject: Re: [edk2-devel] [PATCH v3 3/5] MdeModulePkg: Do nothing on NestedInterruptRestoreTPL(TPL_HIGH_LEVEL)
Date: Tue, 23 Jan 2024 16:59:40 +0000 [thread overview]
Message-ID: <0102018d374367e0-ac396f00-34fb-40ab-8fe6-f68d0458d373-000000@eu-west-1.amazonses.com> (raw)
In-Reply-To: <dcdd7ca5-ab44-6dc6-26b6-bbe5da495246@redhat.com>
On 23/01/2024 16:32, Laszlo Ersek wrote:
> On 1/23/24 16: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.
>>
>> Restoring TPL to TPL_HIGH_LEVEL is always a no-op. Return immediately
>> from NestedInterruptRestoreTPL(TPL_HIGH_LEVEL), so that we do not need
>> to consider the effect of this possible invariant violation on the
>> remainder of the logic.
>
> Feels like the handling logic might as well be "panic" here (except edk2
> does not have a central panic API that's suitable for all platforms). I
> probably missed the previous discussion that led to this patch. Either
> way, it seems reasonable.
>
> Acked-by: Laszlo Ersek <lersek@redhat.com>
Thank you. We can't panic because there are some bootloaders (*cough*
Microsoft *cough*) that illegally call RaiseTPL(TPL_HIGH_LEVEL) and then
even more illegally enable interrupts via STI. Gerd tracked this down
before, which lead to commit
https://github.com/tianocore/edk2/commit/bee67e0c1
I found another way to trigger a RestoreTPL(TPL_HIGH_LEVEL) while I was
testing the self-tests by deliberately breaking
DisableInterruptsOnIret() to fail to disable interrupts. This also
induces a situation in which we end up at TPL_HIGH_LEVEL with interrupts
enabled.
This ended up triggering an assertion (due to the invariant violation)
in NestedInterruptRestoreTPL() before reaching the point in the
self-test that would have reported a more meaningful error message.
Adding the bypass is justifiable on its own merits (as per the reasoning
in the commit), and it avoids needing to add clutter to the complex
logic in NestedInterruptRestoreTPL() just to ensure that the self-test
fails on the desired ASSERT().
I decided against trying to explain all that in the commit message, but
I can have a go if you think it needs to be captured. :)
Thanks,
Michael
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114220): https://edk2.groups.io/g/devel/message/114220
Mute This Topic: https://groups.io/mt/103911606/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
next prev parent reply other threads:[~2024-01-23 16:59 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <17ACFF3FDD20CD9A.13754@groups.io>
2024-01-23 15:31 ` [edk2-devel] [PATCH v3 0/5] MdeModulePkg: Move NestedInterruptTplLib to MdeModulePkg Michael Brown
2024-01-25 12:17 ` Ni, Ray
[not found] ` <20240123153104.2451759-1-mcb30@ipxe.org>
2024-01-23 15:31 ` [edk2-devel] [PATCH v3 1/5] " Michael Brown
2024-01-23 15:31 ` [edk2-devel] [PATCH v3 2/5] MdeModulePkg: Add missing Iret.h to NestedInterruptTplLib sources list Michael Brown
2024-01-23 15:31 ` [edk2-devel] [PATCH v3 3/5] MdeModulePkg: Do nothing on NestedInterruptRestoreTPL(TPL_HIGH_LEVEL) Michael Brown
2024-01-23 16:32 ` Laszlo Ersek
2024-01-23 16:59 ` Michael Brown [this message]
2024-01-24 12:52 ` Laszlo Ersek
2024-01-23 15:31 ` [edk2-devel] [PATCH v3 4/5] MdeModulePkg: Add self-tests for NestedInterruptTplLib Michael Brown
2024-01-23 16:55 ` Laszlo Ersek
2024-01-23 17:41 ` Michael Brown
2024-01-24 12:58 ` Laszlo Ersek
2024-01-24 10:24 ` Ni, Ray
2024-01-24 10:26 ` Ni, Ray
2024-01-23 15:31 ` [edk2-devel] [PATCH v3 5/5] MdeModulePkg: Extend NestedInterruptTplLib to support Arm CPUs Michael Brown
2024-01-23 15:51 ` Ard Biesheuvel
2024-01-23 16:48 ` Michael Brown
2024-01-23 17:10 ` Laszlo Ersek
2024-01-23 17:21 ` Michael Brown
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=0102018d374367e0-ac396f00-34fb-40ab-8fe6-f68d0458d373-000000@eu-west-1.amazonses.com \
--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