[PATCH] x86: Don't allow stackprotector without TSC

[PATCH] x86: Don't allow stackprotector without TSC

[Ben Harris]

On x86, boot_init_stack_canary() unconditionally calls 
__native_read_tsc().  This means that when a kernel with 
CONFIG_CC_STACKPROTECTOR enabled is booted on a CPU without a TSC, the 
kernel hangs at startup.  See <https://bugs.debian.org/766105> for an 
example.

To avoid this, make HAVE_CC_STACKPROTECTOR dependent on X86_TSC, which is 
defined iff all supported processors have a TSC.  Setting the minimum 
processor type to one without TSC thus disables the stack protector, 
making the kernel bootable on such processors.

Signed-off-by: Ben Harris <bjh21@bjh21.me.uk>

---

This patch is against v3.18-rc1.

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index f2327e8..5acee0f 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -129,7 +129,6 @@ config X86
  	select RTC_LIB
  	select HAVE_DEBUG_STACKOVERFLOW
  	select HAVE_IRQ_EXIT_ON_IRQ_STACK if X86_64
-	select HAVE_CC_STACKPROTECTOR
  	select GENERIC_CPU_AUTOPROBE
  	select HAVE_ARCH_AUDITSYSCALL
  	select ARCH_SUPPORTS_ATOMIC_RMW
diff --git a/arch/x86/Kconfig.cpu b/arch/x86/Kconfig.cpu
index 6983314..9626e47 100644
--- a/arch/x86/Kconfig.cpu
+++ b/arch/x86/Kconfig.cpu
@@ -360,6 +360,7 @@ config X86_P6_NOP
  config X86_TSC
  	def_bool y
  	depends on (MWINCHIP3D || MCRUSOE || MEFFICEON || MCYRIXIII || MK7 || MK6 || MPENTIUM4 || MPENTIUMM || MPENTIUMIII || MPENTIUMII || M686 || M586MMX || M586TSC || MK8 || MVIAC3_2 || MVIAC7 || MGEODEGX1 || MGEODE_LX || MCORE2 || MATOM) || X86_64
+	select HAVE_CC_STACKPROTECTOR

  config X86_CMPXCHG64
  	def_bool y

-- 
Ben Harris

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

[Andy Lutomirski]

On 10/23/2014 03:10 PM, Ben Harris wrote:
> On x86, boot_init_stack_canary() unconditionally calls
> __native_read_tsc().  This means that when a kernel with
> CONFIG_CC_STACKPROTECTOR enabled is booted on a CPU without a TSC, the
> kernel hangs at startup.  See <https://bugs.debian.org/766105> for an
> example.
> 
> To avoid this, make HAVE_CC_STACKPROTECTOR dependent on X86_TSC, which
> is defined iff all supported processors have a TSC.  Setting the minimum
> processor type to one without TSC thus disables the stack protector,
> making the kernel bootable on such processors.

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?

--Andy

> 
> Signed-off-by: Ben Harris <bjh21@bjh21.me.uk>
> 
> ---
> 
> This patch is against v3.18-rc1.
> 
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index f2327e8..5acee0f 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -129,7 +129,6 @@ config X86
>      select RTC_LIB
>      select HAVE_DEBUG_STACKOVERFLOW
>      select HAVE_IRQ_EXIT_ON_IRQ_STACK if X86_64
> -    select HAVE_CC_STACKPROTECTOR
>      select GENERIC_CPU_AUTOPROBE
>      select HAVE_ARCH_AUDITSYSCALL
>      select ARCH_SUPPORTS_ATOMIC_RMW
> diff --git a/arch/x86/Kconfig.cpu b/arch/x86/Kconfig.cpu
> index 6983314..9626e47 100644
> --- a/arch/x86/Kconfig.cpu
> +++ b/arch/x86/Kconfig.cpu
> @@ -360,6 +360,7 @@ config X86_P6_NOP
>  config X86_TSC
>      def_bool y
>      depends on (MWINCHIP3D || MCRUSOE || MEFFICEON || MCYRIXIII || MK7
> || MK6 || MPENTIUM4 || MPENTIUMM || MPENTIUMIII || MPENTIUMII || M686 ||
> M586MMX || M586TSC || MK8 || MVIAC3_2 || MVIAC7 || MGEODEGX1 ||
> MGEODE_LX || MCORE2 || MATOM) || X86_64
> +    select HAVE_CC_STACKPROTECTOR
> 
>  config X86_CMPXCHG64
>      def_bool y
> 

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

[Borislav Petkov]

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.

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

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

[Thomas Gleixner]

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