linux-kernel - Re: [PATCH 2/4] x86: clear XD_DISABLED flag on Intel to regain NX

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: <20101110181503.GS5876@outflux.net>
Date:	Wed, 10 Nov 2010 10:15:03 -0800
From:	Kees Cook <kees.cook@...onical.com>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	x86@...nel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/4] x86: clear XD_DISABLED flag on Intel to regain NX

On Wed, Nov 10, 2010 at 06:42:10PM +0100, Andi Kleen wrote:
> > Right, which is why in this code it validates the CPU brand and its
> > family and model to make sure it's safe to read this MSR. The logic
> > is identical to the code in early_init_intel() that also accesses
> > MSR_IA32_MISC_ENABLE. I reviewed the CPU documentation and it seemed
> > to support that MSR_IA32_MISC_ENABLE would be available under those
> > conditions. That said, I only had a limited number of systems available
> > to test it on. If there are adjustments to be made, we can fix them.
> 
> If you can even find out. The system will die silently.
> 
> Usually the main culprits are simulators. VMs etc. Most do ignore unknown
> MSRs, but not all.

Well, that would be a bug in the simulator. :) Those bugs shouldn't cause a
non-trivial group of Linux users to lack NX.

> > > I would rather move this code later into the early init code (before the
> > > second mapping is set up, which is still in time). There the exception
> > > handlers are up and you could handle a #GP if it happens.
> > 
> > The problem is that the page tables are set up before early_init, and Peter
> > Anvin and I did not see a way to move the XD_DISABLE logic any later than
> > where I've put it. Though I should let Peter speak for himself here, as I'm
> > less familiar with that aspect of the code.
> 
> On x86-64 there are two kernel mappings: an early one and a final one.
> The final one is only set up in C code.
> 
> On 32bit there's only a single one, but it could be changed (e.g. 
> only add NX later)

I'm open to reviewing tested alternative patches. But right now, this
method is tested and works, and is based on several rounds of design
compromises/refinements.

-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/