mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Kees Cook <kees.cook@canonical.com>
To: "H. Peter Anvin" <hpa@zytor.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 12:55:44 -0800	[thread overview]
Message-ID: <20091110205544.GZ5129@outflux.net> (raw)
In-Reply-To: <4AF9C627.1070206@zytor.com>

On Tue, Nov 10, 2009 at 11:59:35AM -0800, H. Peter Anvin wrote:
> On 11/10/2009 11:43 AM, Kees Cook wrote:
> > 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".

Ah, yes, very true.

> 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),

Well, I think thinking that even if they turned on the flag in the BIOS,
the non-PAE kernel couldn't do anything about it anyway.  But, from your
example, I see you went with "missing in kernel" anyway.

> 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.

I was trying to be conservative and not have older hardware without PAE
yelling about missing features.  It seemed only worth complaining about
missing NX if PAE was possible (the class of machines without PAE being
larger than those without NX and with PAE).

> So the logic that makes sense would be:
> 
> if (!cpu_has_nx) {

cpu_has_nx is not the same as nx_enabled (due to disable_nx).  Also, why
doesn't set_nx() use cpu_has_nx?  It seems like it does the check
manually?  Should that be cleaned up?

> 	/* 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
> }

How about this?  (Along with the nx_enabled setting in set_nx() for the
64-bit and 32-bit+PAE case.)

        set_nx();
        if (nx_enabled) {
                printk(KERN_INFO "NX (Execute Disable) protection: active\n");
#if defined(CONFIG_X86_32) && !defined(CONFIG_X86_PAE)
        } else if (cpu_has_pae) {
                /* 32bit non-PAE kernel, PAE CPU */
                printk(KERN_NOTICE "Notice: NX (Execute Disable) protection "
                       "cannot be enabled: non-PAE kernel!\n");
#else
        } else {
                /* PAE kernel, PAE CPU, without NX */
                printk(KERN_NOTICE "Notice: NX (Execute Disable) protection "
                       "missing in CPU or disabled in BIOS!\n");
#endif
        }


-- 
Kees Cook
Ubuntu Security Team

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

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-19 18:42 [PATCH] " 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
2009-11-10 20:55                             ` Kees Cook [this message]
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=20091110205544.GZ5129@outflux.net \
    --to=kees.cook@canonical.com \
    --cc=arjan@infradead.org \
    --cc=hpa@zytor.com \
    --cc=jbeulich@novell.com \
    --cc=jeremy.fitzhardinge@citrix.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®