From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mx.groups.io with SMTP id smtpd.web11.32509.1683639127408520960 for ; Tue, 09 May 2023 06:32:07 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=HRAfaVAI; spf=pass (domain: redhat.com, ip: 170.10.129.124, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1683639126; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=KzwklF7jBHW1yrFDCH4V7Myp5jTb5p0q7OShnBpEdRo=; b=HRAfaVAIeGfFOmTF+Eto8pdpDZ74EbycpnBXbUeNM+P5ie9/98tr8/d5VXYPCjFldQ54RD DzW4xJeq3ZL+/c6KoKUomu4MdIVQJ7Mx4FXUB8X6c9cIEr3HRytbIWQ3dwpkb/8pBMRy/H wczjHlFGVj+Hx5SBlHTz3s7drm3vDpw= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-621-I7h6ESOoMwycNd57Kq4Vvw-1; Tue, 09 May 2023 09:32:05 -0400 X-MC-Unique: I7h6ESOoMwycNd57Kq4Vvw-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 0047B3C16E86; Tue, 9 May 2023 13:31:58 +0000 (UTC) Received: from [10.39.192.152] (unknown [10.39.192.152]) by smtp.corp.redhat.com (Postfix) with ESMTPS id A54C163F5F; Tue, 9 May 2023 13:31:56 +0000 (UTC) Message-ID: Date: Tue, 9 May 2023 15:31:55 +0200 MIME-Version: 1.0 Subject: Re: [PATCH v2 0/2] OvmfPkg: Relax assertion that interrupts do not occur at TPL_HIGH_LEVEL To: Michael Brown , devel@edk2.groups.io Cc: Gerd Hoffmann , Oliver Steffen , Pawel Polawski , Jiewen Yao , Ard Biesheuvel , Jordan Justen References: <175D7813A02A6FCA.31428@groups.io> <01020188006a98ab-43bff9af-a85f-4cc9-b044-69fc167b5982-000000@eu-west-1.amazonses.com> From: "Laszlo Ersek" In-Reply-To: <01020188006a98ab-43bff9af-a85f-4cc9-b044-69fc167b5982-000000@eu-west-1.amazonses.com> X-Scanned-By: MIMEDefang 3.1 on 10.11.54.5 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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 > Cc: Gerd Hoffmann > Cc: Oliver Steffen > Cc: Pawel Polawski > Cc: Jiewen Yao > Cc: Ard Biesheuvel > Cc: Jordan Justen > > 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 Many thanks, Laszlo