x86: Configure NX support earlier in setup_arch

A page fault can crash the kernel very early if an NX bit is set in a page table entry, if the CPU doesn't support NX (or if NX support is disabled in the CPU). Move the call to x86_configure_nx() earlier than parse_setup_data(), since that calls early_memremap().

Signed-off-by Stuart Hayes <[email protected]>

---

arch/x86/kernel/setup.c renamed from arch/x86/kernel/setup.c.orig +11 -2

@@ -940,6 +940,17 @@ void __init setup_arch(char **cmdline_p)
 
 	iomem_resource.end = (1ULL << boot_cpu_data.x86_phys_bits) - 1;
 	setup_memory_map();
+
+	/*
+	 * x86_configure_nx() is called before parse_setup_data() to detect
+	 * whether hardware doesn't support NX (so that parse_setup_data()
+	 * can safely call early_memremap() without setting the XD bit in
+	 * the PTE, which can cause an unrecoverable page fault). It may
+	 * then be called again from within noexec_setup() during parsing
+	 * early parameters to honor the respective command line option.
+	 */
+	x86_configure_nx();
+
 	parse_setup_data();
 
 	copy_edd();

@@ -974,15 +985,6 @@ void __init setup_arch(char **cmdline_p)
 	strlcpy(command_line, boot_command_line, COMMAND_LINE_SIZE);
 	*cmdline_p = command_line;
 
-	/*
-	 * x86_configure_nx() is called before parse_early_param() to detect

I haven't received any responses... is there a problem with the patch? Also CCing a couple people.

Quoted 3 lines · Stuart Hayes

I haven't received any responses... is there a problem with the patch? Also CCing a couple people.

I was on vacation last week and am still catching up.

It would also help if you describe the real-world scenario that made you trip over this.

-hpa

Well... I got this issue because a co-worker tripped over it. He had NX disabled in BIOS for some reason, and found that linux wouldn't boot--it hung right after grub2. I guess it took a while to figure out that it was the fact that NX was disabled that caused linux not to come up--and that could happen to other people. I don't know of any real-world scenarios in which someone would actually prefer to run a recent linux kernel with NX disabled, though.

It looks like some of the other boot paths into the kernel automatically clear the XD_DISABLE bit in the MISC_ENABLE MSR in the CPU (in verify_cpu), but that doesn't happen when grub2 jumps to startup_64 in arch/x86/boot/compressed/head_64.S. I guess instead of this patch, I could try to make a patch that turns NX back on (somewhere in startup_64), but since the kernel already supports NX being disabled, so I thought maybe just fixing that would be better. I didn't like seeing the kernel just die without giving any indication of what the problem is.

Quoted 3 lines · Stuart Hayes

Well... I got this issue because a co-worker tripped over it. He had NX disabled in BIOS for some reason, and found that linux wouldn't boot--it hung right after grub2. I guess it took a while to figure

out

Quoted 5 lines

that it was the fact that NX was disabled that caused linux not to come up--and that could happen to other people. I don't know of any real-world scenarios in which someone would actually prefer to run a recent linux kernel with NX disabled, though.

Quoted 7 lines

It looks like some of the other boot paths into the kernel automatically clear the XD_DISABLE bit in the MISC_ENABLE MSR in the CPU (in verify_cpu), but that doesn't happen when grub2 jumps to startup_64 in arch/x86/boot/compressed/head_64.S. I guess instead of this patch, I could try to make a patch that turns NX back on (somewhere in startup_64), but since the kernel already supports NX being disabled, so I thought maybe just fixing that would be better.

I

Quoted 2 lines

didn't like seeing the kernel just die without giving any indication of what the problem is.

Well, hpa and I were talking about this briefly and this NX disabling in the BIOS is probably for some broken legacy applications/OSes. Linux enables NX unconditionally very early because disabling it is a very bad
idea anyway, security-wise.

So, if this is just a random trip over of a co-worker and doesn't have any sensible use case, I'd rather leave it as is an don't fix it at all.

Oh, it is a case of Grub2 utter braindamage. That figures. I guess we need to invoke verify_cpu in yet another place.

Well... I got this issue because a co-worker tripped over it. He had NX disabled in BIOS for some reason, and found that linux wouldn't boot--it hung right after grub2. I guess it took a while to figure out that it was the fact that NX was disabled that caused linux not to come up--and that could happen to other people. I don't know of any real-world scenarios in which someone would actually prefer to run a recent linux kernel with NX disabled, though.

It looks like some of the other boot paths into the kernel automatically clear the XD_DISABLE bit in the MISC_ENABLE MSR in the CPU (in verify_cpu), but that doesn't happen when grub2 jumps to startup_64 in arch/x86/boot/compressed/head_64.S. I guess instead of this patch, I could try to make a patch that turns NX back on (somewhere in startup_64), but since the kernel already supports NX being disabled, so I thought maybe just fixing that would be better. I didn't like seeing the kernel just die without giving any indication of what the problem is.

I feel this can be a valid scenario where user wants to disable the memory protection (NX flag disable) for his requirement, in that case he will hit this issue. So request you to please revisit this patch.

-----Original Message-----
From: Borislav Petkov [mailto:[email protected]]
Sent: Thursday, November 13, 2014 6:01 PM
To: Singh, B B
Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; Jiri Kosina
Subject: Re: [PATCH] x86: Configure NX support earlier in setup_arch

Quoted 3 lines · On Thu, Nov 13, 2014 at 12:09:02PM +0530, [email protected] wrote:

I feel this can be a valid scenario where user wants to disable the memory protection (NX flag disable) for his requirement, in that case he will hit this issue. So request you to please revisit this patch.

First of all, please do not top-post. Here's why:

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

Revisit this patch how? I'm not sure I understand...

Revisit this patch how? I'm not sure I understand...

I feel this can be a valid scenario where user wants to disable the memory protection (NX flag disable) for his requirement, in that case he will hit this issue.