lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 10 Nov 2009 11:59:35 -0800 From: "H. Peter Anvin" <hpa@...or.com> To: Kees Cook <kees.cook@...onical.com> CC: Arjan van de Ven <arjan@...radead.org>, Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, x86@...nel.org, Pekka Enberg <penberg@...helsinki.fi>, Jan Beulich <jbeulich@...ell.com>, Vegard Nossum <vegardno@....uio.no>, Yinghai Lu <yinghai@...nel.org>, Jeremy Fitzhardinge <jeremy.fitzhardinge@...rix.com>, linux-kernel@...r.kernel.org Subject: Re: [PATCH v4] [x86] detect and report lack of NX protections On 11/10/2009 11:43 AM, Kees Cook wrote: > > This is fun. CONFIG_X86_PAE isn't defined for 64-bit, and using > cpu_has_pae on 64-bit is considered a bug. :) > Yeah, it's somewhat obnoxious. This stuff is a result of the 32- and 64-bit code evolving separately for too long. All of this could and should be cleaned up, but it takes a long time. Either way, you can use the explicit form: boot_cpu_has(X86_FEATURE_PAE) just fine, on any platform. However, the only case for which this can be false is for the non-PAE kernel, since the PAE kernels (32 or 64 bits) cannot boot without it. I have personally never liked the cpu_has_* shorthand macros, but they're occasionally useful for things that have to be handled specially on 64 bits. Unfortunately they have spread and people seem to think they're the only way. > Here is the matrix of what I want to see reported about NX at boot time. > How do you recommend this be implemented? > > kernel cpu -> | CPU has PAE | CPU lacks PAE | > | | CPU has NX | CPU lacks NX | | > V +-------------------+-------------------+-----------------+ > 32-bit non-PAE | missing in kernel | missing in kernel | no message | > +-------------------+-------------------+-----------------+ > 32-bit PAE | active * | missing in CPU | no message | > +-------------------+-------------------+-----------------+ > 64-bit | active | missing in CPU | impossible | > +-------------------+-------------------+-----------------+ > The box with the "*" is the only message currently reported by the kernel. The last column should actually be "no message", "impossible", "impossible". I also think "missing in kernel" is misleading in the 32-bit non-PAE, no-NX case (as it would imply that another kernel could do something), and I *really* fail to see why it is in any way different from the "CPU lacks PAE" case -- which also means no NX. "Unavailable in CPU" seems to beat everything. So the logic that makes sense would be: if (!cpu_has_nx) { /* If the CPU can't do it... */ printk(KERN_INFO "cpu: NX protection unavailable in CPU\n"); } else { #if defined(CONFIG_X86_32) && !defined(CONFIG_X86_PAE) /* Non-PAE kernel: NX unavailable */ printk(KERN_NOTICE "cpu: NX protection missing in kernel\n"); #else printk(KERN_INFO "cpu: NX protection active\n"); #endif } -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists