linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Cc: Ingo Molnar <mingo@redhat.com>,
	x86@kernel.org, Thomas Gleixner <tglx@linutronix.de>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Andy Lutomirski <luto@amacapital.net>,
	Cyrill Gorcunov <gorcunov@openvz.org>,
	Borislav Petkov <bp@suse.de>, Andi Kleen <ak@linux.intel.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCHv4 3/4] x86/boot/compressed/64: Introduce place_trampoline()
Date: Thu, 7 Dec 2017 07:30:48 +0100	[thread overview]
Message-ID: <20171207063048.w46rrq2euzhtym3j@gmail.com> (raw)
In-Reply-To: <20171205135942.24634-4-kirill.shutemov@linux.intel.com>


* Kirill A. Shutemov <kirill.shutemov@linux.intel.com> wrote:

> If a bootloader enables 64-bit mode with 4-level paging, we might need to
> switch over to 5-level paging. The switching requires disabling paging.
> It works fine if kernel itself is loaded below 4G.

s/The switching requires disabling paging.
 /The switching requires the disabling of paging.

> But if the bootloader put the kernel above 4G (not sure if anybody does
> this), we would loose control as soon as paging is disabled as code
> becomes unreachable.

Yeah, so instead of the double 'as' which is syntactically right but a bit 
confusing to read, how about something like:

  But if the bootloader put the kernel above 4G (not sure if anybody does
  this), we would loose control as soon as paging is disabled, because the
  code becomes unreachable to the CPU.

?

> To handle the situation, we need a trampoline in lower memory that would
> take care about switching on 5-level paging.

s/would take care about
 /would take care of

> Apart from the trampoline code itself we also need a place to store top
> level page table in lower memory as we don't have a way to load 64-bit
> value into CR3 from 32-bit mode. We only really need 8-bytes there as we
> only use the very first entry of the page table. But we allocate whole
> page anyway.

s/64-bit value
 /64-bit values

s/into CR3 from 32-bit mode
 /into CR3 in 32-bit mode

s/We only really need 8-bytes there
 /We only really need 8 bytes there

s/But we allocate whole page anyway.
 /But we allocate a whole page anyway.

> We cannot have code in the same page as page table because there's
> hazard that a CPU would read page table speculatively and get confused
> seeing garbage.

How about:

  We cannot have the code in the same page as the page table because there's
  a risk that a CPU would read the page table speculatively and get confused
  by seeing garbage. It's never a good idea to have junk in PTE entries
  visible to the CPU.

? (Assuming it's the PTEs that are stored in that page.)

> We also need a small stack in the trampoline to re-enable long mode via
> long return. But stack and code can share the page just fine.

BTW., I'm not sure this is necessarily a good idea: it means writable+executable 
memory, which we generally try to avoid. How complicated would it be to have them 
separate?

> This patch introduces paging_prepare() that checks if we need to enable
> 5-level paging and then finds a right spot in lower memory for the
> trampoline. Then it copies trampoline code there and setups new top
> level page table for 5-level paging.

s/Then it copies trampoline code there
 /Then it copies the trampoline code there

s/and setups new top level page table
 /and sets up the new top level page table

> At this point we do all the preparation, but not yet use trampoline.
> It will be done in the following patch.

s/but not yet use trampoline
 /but don't use trampoline yet

> The trampoline will be used even on 4-level paging machine. This way we
> will get better coverage and keep trampoline code in shape.

s/even on 4-level paging machine
 /even on 4-level paging machines

s/better coverage
 /better test coverage

s/and keep trampoline code in shape
 /and keep the trampoline code in shape

> +	/*
> +	 * paging_prepare() would setup trampoline and check if we need to
> +	 * enable 5-level paging.

s/would setup trampoline
 /would set up the trampoline

>  	 *
> +	 * Address of the trampoline is returned in RAX. The bit 0 is used
> +	 * to encode if we need to enabled 5-level paging.
>  	 *
> +	 * RSI holds real mode data and need to be preserved across
> +	 * a function call.
>  	 */


s/The bit 0
 /Bit 0

s/if we need to enabled 5-level paging
 /if we need to enable 5-level paging

> +	/* Save trampoline address in RCX */

s/Save trampoline address
 /Save the trampoline address

>  	/* Setup data and stack segments */

While at it:

s/Setup
 /Set up

> +	/* Check if la57 is desired and supported */

Please capitalize LA57 consistently!

> +	/*
> +	 * Find a suitable spot for the trampoline.
> +	 * Code is based on reserve_bios_regions().

s/Code is based on
 /This code is based on

> +	/*
> +	 * For 5-level paging, setup current CR3 as the first and
> +	 * the only entry in a new top level page table.

s/setup
 /set up

> +	 *
> +	 * For 4-level paging, trampoline wouldn't touch CR3.
> +	 * KASLR relies on CR3 pointing to _pgtable.
> +	 * See initialize_identity_maps.

Please refer to functions with '...()'

> +	 */
> +	if (l5_required) {
> +		trampoline[TRAMPOLINE_32BIT_PGTABLE_OFF] =
> +			__native_read_cr3() + _PAGE_TABLE_NOENC;

Please don't break lines nonsensically ...

Thanks,

	Ingo

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2017-12-07  6:30 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-05 13:59 [PATCHv4 0/4] x86: 5-level related changes into decompression code Kirill A. Shutemov
2017-12-05 13:59 ` [PATCHv4 1/4] x86/boot/compressed/64: Fix build with GCC < 5 Kirill A. Shutemov
2017-12-07  6:16   ` Ingo Molnar
2017-12-05 13:59 ` [PATCHv4 2/4] x86/boot/compressed/64: Rename pagetable.c to kaslr_64.c Kirill A. Shutemov
2017-12-07  6:17   ` Ingo Molnar
2017-12-05 13:59 ` [PATCHv4 3/4] x86/boot/compressed/64: Introduce place_trampoline() Kirill A. Shutemov
2017-12-07  6:30   ` Ingo Molnar [this message]
2017-12-07  8:17     ` Matthew Wilcox
2017-12-07  8:24       ` Ingo Molnar
2017-12-08 11:07     ` Kirill A. Shutemov
2017-12-08 11:28       ` Ingo Molnar
2017-12-05 13:59 ` [PATCHv4 4/4] x86/boot/compressed/64: Handle 5-level paging boot if kernel is above 4G Kirill A. Shutemov
2017-12-07  7:03   ` Ingo Molnar

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=20171207063048.w46rrq2euzhtym3j@gmail.com \
    --to=mingo@kernel.org \
    --cc=ak@linux.intel.com \
    --cc=bp@suse.de \
    --cc=gorcunov@openvz.org \
    --cc=hpa@zytor.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=luto@amacapital.net \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.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