From: Arvind Sankar <nivedita@alum.mit.edu>
To: Joerg Roedel <jroedel@suse.de>
Cc: Arvind Sankar <nivedita@alum.mit.edu>,
x86@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 4/5] x86/boot/64: Explicitly map boot_params and command line
Date: Thu, 8 Oct 2020 09:57:44 -0400 [thread overview]
Message-ID: <20201008135744.GD2429573@rani.riverdale.lan> (raw)
In-Reply-To: <20201008094836.GH3209@suse.de>
On Thu, Oct 08, 2020 at 11:48:36AM +0200, Joerg Roedel wrote:
> On Wed, Oct 07, 2020 at 03:53:50PM -0400, Arvind Sankar wrote:
> > This is fragile, as boot_params and the command line mappings are
> > required for the main kernel. If EARLY_PRINTK and RANDOMIZE_BASE are
> > disabled, a QEMU/OVMF boot never accesses the command line in the
> > decompressor stub, and so it never gets mapped. The main kernel accesses
> > it from the identity mapping if AMD_MEM_ENCRYPT is enabled, and will
> > crash.
>
> Looked again, and I think that is wrong for boot_params, which are
> touched unconditionally at the beginning of extract_kernel().
Yes, command line is the only thing that actually breaks, but it is more
robust to explicitly make sure boot_params is mapped as well. There's no
specific alignment requirement for boot_params AFAICT, so at least in
theory it's possible that it would be split across a PMD boundary and
only get half-mapped in the decompressor. It's easier not to have to
worry about it.
>
> For the cmdline you are right, but one of CONFIG_ACPI,
> CONFIG_RANDOMIZE_BASE, CONFIG_X86_5LEVEL or CONFIG_EARLY_PRINTK is
> sufficient to have it touched during this boot stage.
>
X86_5LEVEL accesses it before the switch to the new page tables, so that
doesn't help in getting it mapped. ACPI only accesses it if KASLR is
enabled (as well as MEMORY_HOTREMOVE).
Thanks.
next prev parent reply other threads:[~2020-10-08 13:57 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-07 19:53 [PATCH 0/5] Couple of bugfixes to sev-es series Arvind Sankar
2020-10-07 19:53 ` [PATCH 1/5] x86/boot: Initialize boot_params in startup code Arvind Sankar
2020-10-08 9:04 ` Joerg Roedel
2020-10-08 13:44 ` Arvind Sankar
2020-10-07 19:53 ` [PATCH 2/5] x86/boot: Move get_cmd_line_ptr() and COMMAND_LINE_SIZE into misc.h Arvind Sankar
2020-10-08 9:11 ` Joerg Roedel
2020-10-08 9:30 ` Borislav Petkov
2020-10-08 13:47 ` Arvind Sankar
2020-10-08 15:10 ` Borislav Petkov
2020-10-08 15:30 ` Arvind Sankar
2020-10-08 16:16 ` Borislav Petkov
2020-10-07 19:53 ` [PATCH 3/5] x86/boot/64: Change add_identity_map() to take size for ease of use Arvind Sankar
2020-10-08 9:14 ` Joerg Roedel
2020-10-08 13:49 ` Arvind Sankar
2020-10-07 19:53 ` [PATCH 4/5] x86/boot/64: Explicitly map boot_params and command line Arvind Sankar
2020-10-08 9:17 ` Joerg Roedel
2020-10-08 9:48 ` Joerg Roedel
2020-10-08 13:57 ` Arvind Sankar [this message]
2020-10-07 19:53 ` [PATCH 5/5] x86/head/64: Disable stack protection for head$(BITS).o Arvind Sankar
2020-10-08 8:42 ` Joerg Roedel
2020-10-08 14:52 ` Arvind Sankar
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=20201008135744.GD2429573@rani.riverdale.lan \
--to=nivedita@alum.mit.edu \
--cc=jroedel@suse.de \
--cc=linux-kernel@vger.kernel.org \
--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
all inboxes | Powered by JetHome®