Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20210820073429.19457-1-joro@8bytes.org> <e43eb0d137164270bf16258e6d11879e@AcuMS.aculab.com>
 <YR9tSuLyX8QHV5Pv@8bytes.org> <f68a175362984e4abbb0a1da2004c936@AcuMS.aculab.com>
 <YR+Bxgq4aIo1DI8j@8bytes.org>
In-Reply-To: <YR+Bxgq4aIo1DI8j@8bytes.org>
From:   Ard Biesheuvel <ardb@kernel.org>
Date:   Fri, 20 Aug 2021 13:31:36 +0200
Message-ID: <CAMj1kXHj12FQn_488V_9k9k_LE51K=7n3sS9QnN9gkhBgzw-Kw@mail.gmail.com>
Subject: Re: [PATCH] x86/efi: Restore Firmware IDT in before ExitBootServices()
To:     Joerg Roedel <joro@8bytes.org>
Cc:     David Laight <David.Laight@aculab.com>,
        "x86@kernel.org" <x86@kernel.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
        "hpa@zytor.com" <hpa@zytor.com>, Joerg Roedel <jroedel@suse.de>,
        Kees Cook <keescook@chromium.org>,
        Andy Lutomirski <luto@kernel.org>,
        Uros Bizjak <ubizjak@gmail.com>,
        Arvind Sankar <nivedita@alum.mit.edu>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Fabio Aiuto <fabioaiuto83@gmail.com>,
        "stable@vger.kernel.org" <stable@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Fri, 20 Aug 2021 at 12:19, Joerg Roedel <joro@8bytes.org> wrote:
>
> On Fri, Aug 20, 2021 at 09:02:46AM +0000, David Laight wrote:
> > So allocate and initialise the Linux IDT - so entries can be added.
> > But don't execute 'lidt' until later on.
>
> The IDT is needed in this path to handle #VC exceptions caused by CPUID
> instructions. So loading the IDT later is not an option.
>

That does raise a question, though. Does changing the IDT interfere
with the ability of the UEFI boot services to receive and handle the
timer interrupt? Because before ExitBootServices(), that is owned by
the firmware, and UEFI heavily relies on it for everything (event
handling, polling mode block/network drivers, etc)

If restoring the IDT temporarily just papers over this by creating
tiny windows where the timer interrupt starts working again, this is
bad, and we need to figure out another way to address the original
problem.