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 14:25:21 -0800 [thread overview]
Message-ID: <4AF9E851.2000406@zytor.com> (raw)
In-Reply-To: <20091110221537.GB5129@outflux.net>
On 11/10/2009 02:15 PM, Kees Cook wrote:
> 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.
>
We already have call points in setup_arch for check_efer(), which are
where this code needs to be called.
As I said, check_efer() and set_nx() are the 64- and 32-bit versions of
*exactly the same thing*. Furthermore, it looks to me that set_nx() is
simply broken; it forces the bit set in EFER even though it is already
set in head_32.S.
Thus, what we *should* do is:
a) remove set_nx() completely;
b) enable check_efer() on 32 bits;
c) rename check_efer() to something sane, like x86_configure_nx();
Optionally we should just use cpu_has_nx instead of reading EFER.
-hpa
next prev parent reply other threads:[~2009-11-10 22:29 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
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 [this message]
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=4AF9E851.2000406@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.