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] [thread-next>] [day] [month] [year] [list]
Message-ID: <20101110004347.GF5876@outflux.net>
Date:	Tue, 9 Nov 2010 16:43:47 -0800
From:	Kees Cook <kees.cook@...onical.com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	x86@...nel.org, linux-kernel@...r.kernel.org
Subject: Re: [Security] [PATCH v3 0/4] x86: clear XD_DISABLED flag on Intel
 to regain NX

On Wed, Nov 10, 2010 at 12:21:53AM +0000, Alan Cox wrote:
> > Only Intel has this problem (it's the only CPU that defines this MSR), so
> > that'll reduce it. But Google is of no help to me on this; where can I find
> > these documents?
> 
> www.intel.com 8)

Gee, thanks. :P

I looks like there is nothing that actually lists errata directly, so
walking the entire site for lists of all processor types, e.g.:
http://www.intel.com/products/processors/previousgeneration/index.htm
http://www.intel.com/design/celeron/documentation.htm
and then checking spec updates is the only way to go.

> > > I'm not specifically aware of any but I do know for example that there
> > > are other CPU BIOS disablable features that some systems disable in the
> > > BIOS for good reason (an ancient example being the original Pentium
> > > REP MOVS optimisation on some steppings)
> > 
> > By definition there should be fewer errata CPUs than those than need their
> > BIOS ignored, so I still think this patch makes sense (especially since it
> > can trivially be worked around with the noexec=off boot option).
> 
> We need to be sure because the last thing you want is even 1% of your 10%
> of users to sudden get magical random memory corruption from overriding
> something wrongly !
> 
> It's definitely worth checking and worth doing because even if there is
> one (and I have no idea if there is) it'll tell you which steppings

I will report if I find anything bad.

-Kees

-- 
Kees Cook
Ubuntu Security Team
--
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