linux-kernel - Re: [PATCH] x86: Don't allow stackprotector without TSC

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]

Message-ID: <alpine.DEB.2.11.1410252327310.5308@nanos>
Date:	Sat, 25 Oct 2014 23:31:05 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Borislav Petkov <bp@...en8.de>
cc:	Andy Lutomirski <luto@...capital.net>,
	Ben Harris <bjh21@...21.me.uk>, Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>, x86@...nel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86: Don't allow stackprotector without TSC

On Fri, 24 Oct 2014, Borislav Petkov wrote:
> On Thu, Oct 23, 2014 at 04:43:03PM -0700, Andy Lutomirski wrote:
> > Presumably the actual failure is a #GP when trying to do the rdtsc. If
> > so, wouldn't a better fix be to make that rdtsc check cpuid first? Can
> > we easily check cpuid that early?
> 
> I don't see why not.
> 
> The real question, though is, can we have a fallback for RDTSC on those
> machines so that they don't have to disable stack protector in order to
> boot.

The simple solution is to make the rdtsc conditional on the
availability of the feature flag, which is going to be not set on
these kind of machines.

So for the non TSC case we can either leave the extra randomness alone
or readout PIT, which is available and better than nothing.

Thanks,

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