linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Borislav Petkov <bp@alien8.de>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: "Jörg Rödel" <joro@8bytes.org>,
	"Tom Lendacky" <thomas.lendacky@amd.com>,
	"Tao Liu" <ltao@redhat.com>,
	"Michael Roth" <michael.roth@amd.com>,
	tglx@linutronix.de, mingo@redhat.com,
	dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com,
	linux-kernel@vger.kernel.org, bhe@redhat.com, dyoung@redhat.com,
	kexec@lists.infradead.org, linux-efi@vger.kernel.org
Subject: Re: [PATCH v2] x86/kexec: Add EFI config table identity mapping for kexec kernel
Date: Sat, 5 Aug 2023 11:17:38 +0200	[thread overview]
Message-ID: <20230805091738.GAZM4TslVWR3HHKeUC@fat_crate.local> (raw)
In-Reply-To: <CAMj1kXHnSzdQw5CMAVXU7EzpnrdRvAqKZVgA+EV35kHmwVULgQ@mail.gmail.com>

On Thu, Aug 03, 2023 at 01:11:54PM +0200, Ard Biesheuvel wrote:
> Sadly, not only 'old' grubs - GRUB mainline only recently added
> support for booting Linux/x86 via the EFI stub (because I wrote the
> code for them),

haha.

> but it will still fall back to the previous mode for kernels that are
> built without EFI stub support, or which are older than ~v5.8 (because
> their EFI stub does not implement the generic EFI initrd loading
> mechanism)

The thing is, those SNP kernels pretty much use the EFI boot mechanism.
I mean, don't take my word for it as I run SNP guests only from time to
time but that's what everyone uses AFAIK.

> Yeah. what seems to be saving our ass here is that startup_32 maps the
> first 1G of physical address space 4 times, and x86_64 EFI usually
> puts firmware tables below 4G. This means the cc blob check doesn't
> fault, but it may dereference bogus memory traversing the config table
> array looking for the cc blob GUID. However, the system table field
> holding the size of the array may also appear as bogus so this may
> still break in weird ways.

Oh fun.

> I don't think we can kill it yet, but it would be nice if we could
> avoid the need to support SNP boot when entering that way.

That's what I meant - not boot SNP guests through the 32-bit entry path.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

  parent reply	other threads:[~2023-08-05  9:18 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-01  7:20 [PATCH v2] x86/kexec: Add EFI config table identity mapping for kexec kernel Tao Liu
2023-06-01  8:13 ` Baoquan He
2023-06-01  8:25   ` Tao Liu
2023-06-08  7:13     ` Tao Liu
2023-06-16 12:24 ` Baoquan He
2023-07-05 17:33 ` Borislav Petkov
2023-07-07  2:47   ` Dave Young
2023-07-07  3:38   ` Tao Liu
2023-07-07  4:23     ` Baoquan He
2023-07-07  8:22       ` Joerg Roedel
2023-07-07  8:41         ` Baoquan He
2023-07-07  8:57         ` Borislav Petkov
2023-07-07 15:25           ` Michael Roth
2023-07-07 17:12             ` Borislav Petkov
2023-07-13 10:17               ` Ard Biesheuvel
2023-07-17 15:02                 ` Tao Liu
2023-07-07 15:46         ` Tom Lendacky
2023-07-13 10:04 ` Borislav Petkov
2023-07-17 13:53   ` Tao Liu
2023-07-17 14:14     ` Borislav Petkov
2023-07-17 14:24       ` Tao Liu
2023-07-27 11:03       ` Tao Liu
2023-07-28 16:55         ` Borislav Petkov
2023-08-02  8:22           ` Tao Liu
2023-08-02  9:39             ` Borislav Petkov
2023-08-02 13:40               ` Tom Lendacky
2023-08-02 13:58                 ` Borislav Petkov
2023-08-02 14:55                   ` Ard Biesheuvel
2023-08-02 15:51                     ` Borislav Petkov
2023-08-03 11:11                       ` Ard Biesheuvel
2023-08-03 14:27                         ` Ard Biesheuvel
2023-08-05  9:19                           ` Borislav Petkov
2023-08-05  9:17                         ` Borislav Petkov [this message]
2023-08-06  9:00                           ` Ard Biesheuvel
2023-07-17 14:56     ` Ard Biesheuvel
2023-07-17 15:11       ` Tao Liu
2023-07-27 11:11         ` Tao Liu
2023-08-07 16:17 ` [tip: x86/urgent] x86/sev: Do not try to parse for the CC blob on non-AMD hardware tip-bot2 for Borislav Petkov (AMD)

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=20230805091738.GAZM4TslVWR3HHKeUC@fat_crate.local \
    --to=bp@alien8.de \
    --cc=ardb@kernel.org \
    --cc=bhe@redhat.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=dyoung@redhat.com \
    --cc=hpa@zytor.com \
    --cc=joro@8bytes.org \
    --cc=kexec@lists.infradead.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ltao@redhat.com \
    --cc=michael.roth@amd.com \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=thomas.lendacky@amd.com \
    --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;
as well as URLs for NNTP newsgroup(s).