[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4AF9E851.2000406@zytor.com>
Date: Tue, 10 Nov 2009 14:25:21 -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 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
--
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