linux-kernel - Re: [PATCH] x86/efi: Restore Firmware IDT in before ExitBootServices()

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <YR+XO+zcwoNytZSj@suse.de>
Date:   Fri, 20 Aug 2021 13:51:23 +0200
From:   Joerg Roedel <jroedel@...e.de>
To:     Ard Biesheuvel <ardb@...nel.org>
Cc:     Joerg Roedel <joro@...tes.org>,
        David Laight <David.Laight@...lab.com>,
        "x86@...nel.org" <x86@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        "hpa@...or.com" <hpa@...or.com>, Kees Cook <keescook@...omium.org>,
        Andy Lutomirski <luto@...nel.org>,
        Uros Bizjak <ubizjak@...il.com>,
        Arvind Sankar <nivedita@...m.mit.edu>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Fabio Aiuto <fabioaiuto83@...il.com>,
        "stable@...r.kernel.org" <stable@...r.kernel.org>
Subject: Re: [PATCH] x86/efi: Restore Firmware IDT in before
 ExitBootServices()

On Fri, Aug 20, 2021 at 01:31:36PM +0200, Ard Biesheuvel wrote:
> 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)

Yes it would interfer, if the boot code would run with IRQs enabled,
which it does not. But switching the GDT also interfers with that, and
we are doing the same switching with the GDT already.

> 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.

As I can see it, there is no time window where an interrupt could happen
(NMIs aside). When returning from EFI IRQs are disabled again (in case
EFI let them enabled) while still on the EFI GDT and IDT. After IRQs are
disabled the kernel restores its own GDT and IDT.

Regards,

	Joerg