lists.openwall.net   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  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Sat, 19 Jun 2010 11:08:13 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Kees Cook <kees.cook@...onical.com>,
	Arjan van de Ven <arjan@...radead.org>
CC:	Andi Kleen <andi@...stfloor.org>, x86@...nel.org,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	Alexander Potashev <aspotashev@...il.com>,
	Tim Abbott <tabbott@...lice.com>,
	Sam Ravnborg <sam@...nborg.org>,
	Jan Beulich <jbeulich@...ell.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@...rix.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 0/4] x86: clear XD_DISABLED flag on Intel to regain NX

SMM is not affected; it doesn't use the kernel page tables.

"Kees Cook" <kees.cook@...onical.com> wrote:

>Hi,
>
>On Sat, Jun 19, 2010 at 08:16:42AM -0700, Arjan van de Ven wrote:
>> On Sat, 19 Jun 2010 10:21:29 +0200
>> Andi Kleen <andi@...stfloor.org> wrote:
>> 
>> > Kees Cook <kees.cook@...onical.com> writes:
>> > 
>> > > This will clear the MSR_IA32_MISC_ENABLE_XD_DISABLE bit so that NX
>> > > cannot be inappropriately controlled by the BIOS on Intel CPUs.  If
>> > > NX actually needs to be disabled, "noexec=off" can be used.
>> > 
>> > The patch still seems like a bad idea to me. What happens if 
>> > the NX bit is broken for some reason and the BIOS is right
>> > to disable it?
>> 
>> 
>> overriding the bios like this is almost always a bad idea.
>> (you're doing a blanket override, not a specific, verified override)
>
>I've seen other things in the BIOS ignored (IDE bus settings jumps to
>mind), so I figured it wasn't strictly bad.  From what I've been able to
>gather, this setting is never correct.  If there are situations where it
>must be left alone, we could add those as exceptions.
>
>> you have no idea if the SMM code can deal with NX, etc etc.
>
>The pages don't get marked as actually NX until setup_nx() is called, at
>which point "noexec=off" would have already been handled, so if that
>happens, a system can still boot with that cmdline option.
>
>> the real answer is "fix your bios setting".
>
>Well, the "best" answer is "fix the bios", which is why I got Dell to
>fix their BIOSes.  Unfortunately, there are still systems with this
>misconfigured.
>
>> Don't as owner of the machine turn something off in the bios that you
>> actually want.
>
>Most people don't know/care, so if they do and it's a problem, I thought
>using "noexec=off" would be sufficient while still allowing the bulk of
>systems to end up with NX correctly enabled.
>
>-Kees
>
>-- 
>Kees Cook
>Ubuntu Security Team

-- 
Sent from my mobile phone.  Please pardon any lack of formatting.
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ