RE: [PATCH] x86: Configure NX support earlier in setup_arch
From: B_B_Singh
Date: Thu Nov 13 2014 - 01:48:46 EST
Hi Boris,
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.
Regards
Balaji Singh
-----Original Message-----
From: linux-kernel-owner@xxxxxxxxxxxxxxx [mailto:linux-kernel-owner@xxxxxxxxxxxxxxx] On Behalf Of Borislav Petkov
Sent: Monday, July 14, 2014 10:52 PM
To: Stuart Hayes
Cc: H. Peter Anvin; tglx@xxxxxxxxxxxxx; mingo@xxxxxxxxxx; x86@xxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; matt.fleming@xxxxxxxxx; bp@xxxxxxx
Subject: Re: [PATCH] x86: Configure NX support earlier in setup_arch
On Wed, Jul 09, 2014 at 07:56:29PM -0500, Stuart Hayes wrote:
> 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.
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.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/