From: Thomas Gleixner <tglx@linutronix.de>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
"Niklāvs Koļesņikovs" <pinkflames.linux@gmail.com>,
linux-efi@vger.kernel.org, x86@kernel.org,
regressions@lists.linux.dev
Subject: Re: x86/efi: Make efi_set_virtual_address_map IBT safe
Date: Thu, 29 Jun 2023 23:45:13 +0200 [thread overview]
Message-ID: <878rc20wpi.ffs@tglx> (raw)
In-Reply-To: <CAMj1kXG0GZ8K4kVux3zQ6TXGoeQ8bwHq7JXbx-YXFbLSbD-6Gg@mail.gmail.com>
On Thu, Jun 29 2023 at 23:42, Ard Biesheuvel wrote:
> On Thu, 29 Jun 2023 at 21:35, Thomas Gleixner <tglx@linutronix.de> wrote:
>> Niklāvs reported a boot regression on an Alderlake machine and bisected it
>> to commit 9df9d2f0471b ("init: Invoke arch_cpu_finalize_init() earlier").
>>
>> By moving the invocation of arch_cpu_finalize_init() further down he
>> identified that efi_enter_virtual_mode() is the function which causes
>> the boot hang.
>>
>> The main difference of the earlier invocation is that the boot CPU is
>> already fully initialized and mitigations and alternatives are applied.
>>
>> But the only really interesting change turned out to be IBT, which is
>> now enabled before efi_enter_virtual_mode(). "ibt=off" on the kernel
>> command line cured the problem.
>>
>> Inspection of the involved calls in efi_enter_virtual_mode() unearthed that
>> efi_set_virtual_address_map() is the only place in the kernel which invokes
>> an EFI call without the IBT safe wrapper. This went obviously unnoticed so
>> far as IBT was enabled later.
>>
>> Use arch_efi_call_virt() instead of efi_call() to cure that.
>>
>> Fixes: fe379fa4d199 ("x86/ibt: Disable IBT around firmware")
>> Fixes: 9df9d2f0471b ("init: Invoke arch_cpu_finalize_init() earlier")
>> Reported-by: Niklāvs Koļesņikovs <pinkflames.linux@gmail.com>
>> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
>> Link: https://bugzilla.kernel.org/show_bug.cgi?id=217602
>
> Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
>
> I take it you'll send this straight to Linus?
I can do that.
Thanks,
tglx
next prev parent reply other threads:[~2023-06-29 21:45 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-29 19:35 x86/efi: Make efi_set_virtual_address_map IBT safe Thomas Gleixner
2023-06-29 21:42 ` Ard Biesheuvel
2023-06-29 21:45 ` Thomas Gleixner [this message]
2023-06-30 13:32 ` [tip: x86/urgent] " tip-bot2 for Thomas Gleixner
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-all 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=878rc20wpi.ffs@tglx \
--to=tglx@linutronix.de \
--cc=ardb@kernel.org \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pinkflames.linux@gmail.com \
--cc=regressions@lists.linux.dev \
--cc=x86@kernel.org \
/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