Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757137AbZKJWQm (ORCPT ); Tue, 10 Nov 2009 17:16:42 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753765AbZKJWQl (ORCPT ); Tue, 10 Nov 2009 17:16:41 -0500 Received: from smtp.outflux.net ([198.145.64.163]:59886 "EHLO smtp.outflux.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753259AbZKJWQl (ORCPT ); Tue, 10 Nov 2009 17:16:41 -0500 Date: Tue, 10 Nov 2009 14:15:37 -0800 From: Kees Cook To: "H. Peter Anvin" Cc: Arjan van de Ven , Thomas Gleixner , Ingo Molnar , x86@kernel.org, Pekka Enberg , Jan Beulich , Vegard Nossum , Yinghai Lu , Jeremy Fitzhardinge , linux-kernel@vger.kernel.org Subject: Re: [PATCH v4] [x86] detect and report lack of NX protections Message-ID: <20091110221537.GB5129@outflux.net> References: <20091110154956.GF5129@outflux.net> <4AF9991B.20400@zytor.com> <20091110165738.GH5129@outflux.net> <4AF99F0C.2050806@zytor.com> <20091110174622.GK5129@outflux.net> <4AF9B6AD.8020505@zytor.com> <20091110194304.GW5129@outflux.net> <4AF9C627.1070206@zytor.com> <20091110205544.GZ5129@outflux.net> <4AF9D98A.90808@zytor.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AF9D98A.90808@zytor.com> Organization: Canonical X-HELO: www.outflux.net Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3763 Lines: 123 On Tue, Nov 10, 2009 at 01:22:18PM -0800, H. Peter Anvin wrote: > Yes, it should be. set_nx() and check_efer() are doing the same thing, > except in different ways, and they are - IMO - *both* doing something > dumb -- although check_efer() is saner. BTW, it seems like set_nx() should move from init_memory_mapping to setup_arch, since init_memory_mapping can be called twice, but I don't think set_nx needs to be. Also, disable_nx is only defined in setup_nx.c when "defined(CONFIG_X86_64) || defined(CONFIG_X86_PAE)", so I re-arranged the logic to match that. How about the following clean-up and merge... --- It is possible for x86_64 systems to lack the NX bit (see check_efer()) either due to the hardware lacking support or the BIOS having turned off the CPU capability, so NX status should be reported. Additionally, anyone booting NX-capable CPUs in 32bit mode without PAE will lack NX functionality, so this change provides feedback for that case as well. Signed-off-by: Kees Cook --- arch/x86/kernel/setup.c | 2 ++ arch/x86/mm/init.c | 4 ---- arch/x86/mm/setup_nx.c | 31 ++++++++++++++++++++----------- 3 files changed, 22 insertions(+), 15 deletions(-) diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c index e09f0e2..72181c1 100644 --- a/arch/x86/kernel/setup.c +++ b/arch/x86/kernel/setup.c @@ -895,6 +895,8 @@ void __init setup_arch(char **cmdline_p) init_gbpages(); + set_nx(); + /* max_pfn_mapped is updated here */ max_low_pfn_mapped = init_memory_mapping(0, max_low_pfn< 0x80000001)) { - cpuid(0x80000001, &v[0], &v[1], &v[2], &v[3]); + if (!cpu_has_nx) { + printk(KERN_NOTICE "Notice: NX (Execute Disable) protection " + "missing in CPU or disabled in BIOS!\n"); + } else { +#if defined(CONFIG_X86_64) || defined(CONFIG_X86_PAE) + if (disable_nx) + printk(KERN_INFO "NX (Execute Disable) protection: " + "disabled by kernel command line option\n"); + else { +# ifdef CONFIG_X86_PAE + /* 32-bit PAE */ + unsigned int l, h; - if ((v[3] & (1 << 20)) && !disable_nx) { rdmsr(MSR_EFER, l, h); l |= EFER_NX; wrmsr(MSR_EFER, l, h); nx_enabled = 1; __supported_pte_mask |= _PAGE_NX; +# endif + printk(KERN_INFO "NX (Execute Disable) protection: " + "active\n"); } - } -} #else -void set_nx(void) -{ -} + /* 32bit non-PAE kernel, NX cannot be used */ + printk(KERN_NOTICE "Notice: NX (Execute Disable) protection " + "cannot be enabled: non-PAE kernel!\n"); #endif + } +} #ifdef CONFIG_X86_64 void __cpuinit check_efer(void) -- 1.6.5 -- Kees Cook Ubuntu Security Team -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/