All of lore.kernel.org
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: Kees Cook <kees.cook@canonical.com>
Cc: Arjan van de Ven <arjan@infradead.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>,
	x86@kernel.org, Pekka Enberg <penberg@cs.helsinki.fi>,
	Jan Beulich <jbeulich@novell.com>,
	Vegard Nossum <vegardno@ifi.uio.no>,
	Yinghai Lu <yinghai@kernel.org>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4] [x86] detect and report lack of NX protections
Date: Tue, 10 Nov 2009 11:59:35 -0800	[thread overview]
Message-ID: <4AF9C627.1070206@zytor.com> (raw)
In-Reply-To: <20091110194304.GW5129@outflux.net>

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
}

  reply	other threads:[~2009-11-10 20:03 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-19 18:42 [PATCH] [x86] detect and report lack of NX protections Kees Cook
2009-10-19 23:43 ` Arjan van de Ven
2009-10-20  2:04   ` [PATCH v2] " Kees Cook
2009-10-20  2:18     ` H. Peter Anvin
2009-10-20  4:44       ` Kees Cook
2009-10-20  4:55       ` [PATCH v3] " Kees Cook
2009-11-09 22:10         ` [PATCH v4] " Kees Cook
2009-11-09 23:16           ` H. Peter Anvin
2009-11-10 15:49             ` Kees Cook
2009-11-10 16:47               ` H. Peter Anvin
2009-11-10 16:57                 ` Kees Cook
2009-11-10 17:12                   ` H. Peter Anvin
2009-11-10 17:46                     ` Kees Cook
2009-11-10 18:53                       ` H. Peter Anvin
2009-11-10 19:43                         ` Kees Cook
2009-11-10 19:59                           ` H. Peter Anvin [this message]
2009-11-10 20:55                             ` Kees Cook
2009-11-10 21:22                               ` H. Peter Anvin
2009-11-10 22:15                                 ` Kees Cook
2009-11-10 22:25                                   ` H. Peter Anvin
2009-11-12 18:01                               ` Yuhong Bao
2009-11-10 20:25                           ` H. Peter Anvin
2009-11-10 16:55           ` [PATCH v5] " Kees Cook

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=4AF9C627.1070206@zytor.com \
    --to=hpa@zytor.com \
    --cc=arjan@infradead.org \
    --cc=jbeulich@novell.com \
    --cc=jeremy.fitzhardinge@citrix.com \
    --cc=kees.cook@canonical.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=penberg@cs.helsinki.fi \
    --cc=tglx@linutronix.de \
    --cc=vegardno@ifi.uio.no \
    --cc=x86@kernel.org \
    --cc=yinghai@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.