mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: tip-bot for Andy Lutomirski <tipbot@zytor.com>
To: linux-tip-commits@vger.kernel.org
Cc: tglx@linutronix.de, torvalds@linux-foundation.org,
	luto@kernel.org, jikos@kernel.org, hpa@zytor.com,
	bpetkov@suse.de, linux-kernel@vger.kernel.org, jkosina@suse.cz,
	mingo@kernel.org, peterz@infradead.org
Subject: [tip:x86/urgent] x86/hibernate/64: Mask off CR3's PCID bits in the saved CR3
Date: Wed, 13 Sep 2017 01:55:34 -0700	[thread overview]
Message-ID: <tip-f34902c5c6c08024371202a680ce69f2d488776d@git.kernel.org> (raw)
In-Reply-To: <18ca57090651a6341e97083883f9e814c4f14684.1504847163.git.luto@kernel.org>

Commit-ID:  f34902c5c6c08024371202a680ce69f2d488776d
Gitweb:     http://git.kernel.org/tip/f34902c5c6c08024371202a680ce69f2d488776d
Author:     Andy Lutomirski <luto@kernel.org>
AuthorDate: Thu, 7 Sep 2017 22:06:58 -0700
Committer:  Ingo Molnar <mingo@kernel.org>
CommitDate: Wed, 13 Sep 2017 09:52:37 +0200

x86/hibernate/64: Mask off CR3's PCID bits in the saved CR3

Jiri reported a resume-from-hibernation failure triggered by PCID.
The root cause appears to be rather odd.  The hibernation asm
restores a CR3 value that comes from the image header.  If the image
kernel has PCID on, it's entirely reasonable for this CR3 value to
have one of the low 12 bits set.  The restore code restores it with
CR4.PCIDE=0, which means that those low 12 bits are accepted by the
CPU but are either ignored or interpreted as a caching mode.  This
is odd, but still works.  We blow up later when the image kernel
restores CR4, though, since changing CR4.PCIDE with CR3[11:0] != 0
is illegal.  Boom!

FWIW, it's entirely unclear to me what's supposed to happen if a PAE
kernel restores a non-PAE image or vice versa.  Ditto for LA57.

Reported-by: Jiri Kosina <jikos@kernel.org>
Tested-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bpetkov@suse.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Fixes: 660da7c9228f ("x86/mm: Enable CR4.PCIDE on supported systems")
Link: http://lkml.kernel.org/r/18ca57090651a6341e97083883f9e814c4f14684.1504847163.git.luto@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
---
 arch/x86/power/hibernate_64.c | 21 ++++++++++++++++++++-
 1 file changed, 20 insertions(+), 1 deletion(-)

diff --git a/arch/x86/power/hibernate_64.c b/arch/x86/power/hibernate_64.c
index f2598d8..f910c51 100644
--- a/arch/x86/power/hibernate_64.c
+++ b/arch/x86/power/hibernate_64.c
@@ -295,7 +295,26 @@ int arch_hibernation_header_save(void *addr, unsigned int max_size)
 		return -EOVERFLOW;
 	rdr->jump_address = (unsigned long)restore_registers;
 	rdr->jump_address_phys = __pa_symbol(restore_registers);
-	rdr->cr3 = restore_cr3;
+
+	/*
+	 * The restore code fixes up CR3 and CR4 in the following sequence:
+	 *
+	 * [in hibernation asm]
+	 * 1. CR3 <= temporary page tables
+	 * 2. CR4 <= mmu_cr4_features (from the kernel that restores us)
+	 * 3. CR3 <= rdr->cr3
+	 * 4. CR4 <= mmu_cr4_features (from us, i.e. the image kernel)
+	 * [in restore_processor_state()]
+	 * 5. CR4 <= saved CR4
+	 * 6. CR3 <= saved CR3
+	 *
+	 * Our mmu_cr4_features has CR4.PCIDE=0, and toggling
+	 * CR4.PCIDE while CR3's PCID bits are nonzero is illegal, so
+	 * rdr->cr3 needs to point to valid page tables but must not
+	 * have any of the PCID bits set.
+	 */
+	rdr->cr3 = restore_cr3 & ~CR3_PCID_MASK;
+
 	rdr->magic = RESTORE_MAGIC;
 
 	hibernation_e820_save(rdr->e820_digest);

      parent reply	other threads:[~2017-09-13  8:59 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-08  5:06 [PATCH 0/2] More PCID fixes Andy Lutomirski
2017-09-08  5:06 ` [PATCH 1/2] x86/mm: Get rid of VM_BUG_ON in switch_tlb_irqs_off() Andy Lutomirski
2017-09-08  5:09   ` Andy Lutomirski
2017-09-13  8:55   ` [tip:x86/urgent] " tip-bot for Andy Lutomirski
2017-09-08  5:06 ` [PATCH 2/2] x86/hibernate/64: Mask off CR3's PCID bits in the saved CR3 Andy Lutomirski
2017-09-08  7:59   ` Jiri Kosina
2017-09-10 19:17     ` Andy Lutomirski
2017-09-11  5:48       ` Ingo Molnar
2017-09-13  8:55   ` tip-bot for Andy Lutomirski [this message]

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=tip-f34902c5c6c08024371202a680ce69f2d488776d@git.kernel.org \
    --to=tipbot@zytor.com \
    --cc=bpetkov@suse.de \
    --cc=hpa@zytor.com \
    --cc=jikos@kernel.org \
    --cc=jkosina@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tip-commits@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.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

Powered by JetHome