All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Lutomirski <luto@amacapital.net>
To: Ben Harris <bjh21@bjh21.me.uk>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	x86@kernel.org
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] x86: Don't allow stackprotector without TSC
Date: Thu, 23 Oct 2014 16:43:03 -0700	[thread overview]
Message-ID: <54499287.5070803@amacapital.net> (raw)
In-Reply-To: <alpine.DEB.2.10.1410232227580.28125@snap.ds.cam.ac.uk>

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
> 


  reply	other threads:[~2014-10-23 23:43 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-23 22:10 [PATCH] x86: Don't allow stackprotector without TSC Ben Harris
2014-10-23 23:43 ` Andy Lutomirski [this message]
2014-10-24 12:03   ` Borislav Petkov
2014-10-25 21:31     ` Thomas Gleixner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54499287.5070803@amacapital.net \
    --to=luto@amacapital.net \
    --cc=bjh21@bjh21.me.uk \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.