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
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 10 Nov 2009 14:25:21 -0800
From:	"H. Peter Anvin" <>
To:	Kees Cook <>
CC:	Arjan van de Ven <>,
	Thomas Gleixner <>,
	Ingo Molnar <>,,
	Pekka Enberg <>,
	Jan Beulich <>,
	Vegard Nossum <>,
	Yinghai Lu <>,
	Jeremy Fitzhardinge <>,
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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists