public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Laszlo Ersek" <lersek@redhat.com>
To: Michael Brown <mcb30@ipxe.org>, devel@edk2.groups.io
Cc: Gerd Hoffmann <kraxel@redhat.com>,
	Oliver Steffen <osteffen@redhat.com>,
	Pawel Polawski <ppolawsk@redhat.com>,
	Jiewen Yao <jiewen.yao@intel.com>,
	Ard Biesheuvel <ardb+tianocore@kernel.org>,
	Jordan Justen <jordan.l.justen@intel.com>
Subject: Re: [PATCH 0/2] OvmfPkg: Relax assertion that interrupts do not occur at TPL_HIGH_LEVEL
Date: Tue, 9 May 2023 10:43:06 +0200	[thread overview]
Message-ID: <50bf1804-70ba-dfff-73ad-d2afdbedf5e7@redhat.com> (raw)
In-Reply-To: <01020187fd46b80f-a69b4ae5-545f-45ae-ab0d-a48f725c7a40-000000@eu-west-1.amazonses.com>

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


  parent reply	other threads:[~2023-05-09  8:43 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-03  7:19 [PATCH v2 1/1] OvmfPkg/NestedInterruptTplLib: replace ASSERT() with a warning logged Gerd Hoffmann
2023-05-05 14:10 ` [edk2-devel] " Michael Brown
2023-05-05 18:56   ` Laszlo Ersek
2023-05-05 23:27     ` Michael Brown
2023-05-05 23:57       ` Ard Biesheuvel
2023-05-08  6:45         ` Laszlo Ersek
2023-05-09  9:13           ` Ard Biesheuvel
2023-05-08  6:38       ` Laszlo Ersek
2023-05-08 21:31         ` [PATCH 0/2] OvmfPkg: Relax assertion that interrupts do not occur at TPL_HIGH_LEVEL Michael Brown
2023-05-09  7:05           ` Gerd Hoffmann
2023-05-09  8:43           ` Laszlo Ersek [this message]
2023-05-09 12:08             ` [edk2-devel] " Michael Brown
2023-05-09 13:27               ` Laszlo Ersek
     [not found]         ` <20230508213100.3949708-1-mcb30@ipxe.org>
2023-05-08 21:31           ` [PATCH 1/2] OvmfPkg: Clarify invariants for NestedInterruptTplLib Michael Brown
2023-05-08 21:31           ` [PATCH 2/2] OvmfPkg: Relax assertion that interrupts do not occur at TPL_HIGH_LEVEL Michael Brown
2023-05-09  8:35             ` Laszlo Ersek
2023-05-09  9:42               ` Gerd Hoffmann
2023-05-09 12:04               ` [edk2-devel] " 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=50bf1804-70ba-dfff-73ad-d2afdbedf5e7@redhat.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