From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id ADFC5C432BE for ; Fri, 20 Aug 2021 11:51:29 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 900EE610C8 for ; Fri, 20 Aug 2021 11:51:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239629AbhHTLwF (ORCPT ); Fri, 20 Aug 2021 07:52:05 -0400 Received: from smtp-out1.suse.de ([195.135.220.28]:49454 "EHLO smtp-out1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237633AbhHTLwE (ORCPT ); Fri, 20 Aug 2021 07:52:04 -0400 Received: from imap1.suse-dmz.suse.de (imap1.suse-dmz.suse.de [192.168.254.73]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 1299821F0F; Fri, 20 Aug 2021 11:51:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1629460286; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=lQX6jTsCnZm0NKaaIyjtENrWZHYlokhpMZqMbbJK9oY=; b=PxOAnuTEltysmL4b7KdcszsAgN/Y48Hzk9NpdbkGvNxcs5EUV2Gn9Q7AqKbEDQYE890cVm t+1znAVlpxJdZySabgIiIiVKBAeYuPwmsuPQixcGvw+u7TwvonZBmBJ7tkPc9G+AEufQbs 0Libt0maUztxeUzdocMRrlWeJHosNwE= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1629460286; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=lQX6jTsCnZm0NKaaIyjtENrWZHYlokhpMZqMbbJK9oY=; b=3WpUwwKY+CKgWY45HtwvGmylJA4P1p6ZuA3BaQ93eB6NHHuOQ3srVPeuksrF3sZT45hJ7U J69ext1up+eyjpDQ== Received: from imap1.suse-dmz.suse.de (imap1.suse-dmz.suse.de [192.168.254.73]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap1.suse-dmz.suse.de (Postfix) with ESMTPS id 81B4D13AC1; Fri, 20 Aug 2021 11:51:25 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap1.suse-dmz.suse.de with ESMTPSA id y4nkHT2XH2FIfQAAGKfGzw (envelope-from ); Fri, 20 Aug 2021 11:51:25 +0000 Date: Fri, 20 Aug 2021 13:51:23 +0200 From: Joerg Roedel To: Ard Biesheuvel Cc: Joerg Roedel , David Laight , "x86@kernel.org" , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "hpa@zytor.com" , Kees Cook , Andy Lutomirski , Uros Bizjak , Arvind Sankar , "linux-kernel@vger.kernel.org" , Fabio Aiuto , "stable@vger.kernel.org" Subject: Re: [PATCH] x86/efi: Restore Firmware IDT in before ExitBootServices() Message-ID: References: <20210820073429.19457-1-joro@8bytes.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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