All of lore.kernel.org
 help / color / mirror / Atom feed
From: aryabinin@virtuozzo.com (Andrey Ryabinin)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arm64: kasan: clear stale stack poison
Date: Fri, 26 Feb 2016 17:00:50 +0300	[thread overview]
Message-ID: <56D05A92.7070802@virtuozzo.com> (raw)
In-Reply-To: <1455816458-19485-1-git-send-email-mark.rutland@arm.com>

On 02/18/2016 08:27 PM, Mark Rutland wrote:
> This patch is a followup to the discussion in [1].
> 
> When using KASAN and CPU idle and/or CPU hotplug, KASAN leaves the stack shadow
> poisoned on exit from the kernel, and this poison is later hit when a CPU is
> brought online and reuses that portion of the stack. Hitting the poison depends
> on stackframe layout, so the bug only manifests in some configurations.
> 
> I think that the hotplug issue is generic, and x86 is affected. I couldn't spot
> magic around idle, so x86 may be fine there. It would be great if someone
> familiar with the x86 code could prove/disprove either of those assertions.
> 
> If x86 is affected, it likely makes sense to unpoison the stack in common code
> prior to bringing a CPU online to avoid that.
> 

I think x86 need that unpoisoning. do_boot_cpu() resets stack for secondary cpu,
so it could be possible to hit stale shadow.

static int do_boot_cpu(int apicid, int cpu, struct task_struct *idle)
{
....
	idle->thread.sp = (unsigned long) (((struct pt_regs *)
			  (THREAD_SIZE +  task_stack_page(idle))) - 1);

	early_gdt_descr.address = (unsigned long)get_cpu_gdt_table(cpu);
	initial_code = (unsigned long)start_secondary;
	stack_start  = idle->thread.sp;




> For idle I'm not keen on having to perform a memset of THREAD_SIZE/8 every time
> a CPU re-enters the kernel. I don't yet have numbers for how bad that is, but
> it doesn't sound good.
> 
> Thanks,
> Mark.
> 
> [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-February/408961.html
> 

WARNING: multiple messages have this Message-ID (diff)
From: Andrey Ryabinin <aryabinin@virtuozzo.com>
To: Mark Rutland <mark.rutland@arm.com>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>
Cc: <akpm@linux-foundation.org>, <hpa@linux.intel.com>,
	<mingo@kernel.org>, <tglx@linutronix.de>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	Will Deacon <will.deacon@arm.com>
Subject: Re: [PATCH] arm64: kasan: clear stale stack poison
Date: Fri, 26 Feb 2016 17:00:50 +0300	[thread overview]
Message-ID: <56D05A92.7070802@virtuozzo.com> (raw)
In-Reply-To: <1455816458-19485-1-git-send-email-mark.rutland@arm.com>

On 02/18/2016 08:27 PM, Mark Rutland wrote:
> This patch is a followup to the discussion in [1].
> 
> When using KASAN and CPU idle and/or CPU hotplug, KASAN leaves the stack shadow
> poisoned on exit from the kernel, and this poison is later hit when a CPU is
> brought online and reuses that portion of the stack. Hitting the poison depends
> on stackframe layout, so the bug only manifests in some configurations.
> 
> I think that the hotplug issue is generic, and x86 is affected. I couldn't spot
> magic around idle, so x86 may be fine there. It would be great if someone
> familiar with the x86 code could prove/disprove either of those assertions.
> 
> If x86 is affected, it likely makes sense to unpoison the stack in common code
> prior to bringing a CPU online to avoid that.
> 

I think x86 need that unpoisoning. do_boot_cpu() resets stack for secondary cpu,
so it could be possible to hit stale shadow.

static int do_boot_cpu(int apicid, int cpu, struct task_struct *idle)
{
....
	idle->thread.sp = (unsigned long) (((struct pt_regs *)
			  (THREAD_SIZE +  task_stack_page(idle))) - 1);

	early_gdt_descr.address = (unsigned long)get_cpu_gdt_table(cpu);
	initial_code = (unsigned long)start_secondary;
	stack_start  = idle->thread.sp;




> For idle I'm not keen on having to perform a memset of THREAD_SIZE/8 every time
> a CPU re-enters the kernel. I don't yet have numbers for how bad that is, but
> it doesn't sound good.
> 
> Thanks,
> Mark.
> 
> [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-February/408961.html
> 

  parent reply	other threads:[~2016-02-26 14:00 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-18 17:27 [PATCH] arm64: kasan: clear stale stack poison Mark Rutland
2016-02-18 17:27 ` Mark Rutland
2016-02-18 17:54 ` Catalin Marinas
2016-02-18 17:54   ` Catalin Marinas
2016-02-18 18:03   ` Will Deacon
2016-02-18 18:03     ` Will Deacon
2016-02-18 18:13     ` Catalin Marinas
2016-02-18 18:13       ` Catalin Marinas
2016-02-19 10:52       ` Lorenzo Pieralisi
2016-02-19 10:52         ` Lorenzo Pieralisi
2016-02-19 11:35       ` Mark Rutland
2016-02-19 11:35         ` Mark Rutland
2016-02-26 14:00 ` Andrey Ryabinin [this message]
2016-02-26 14:00   ` Andrey Ryabinin

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=56D05A92.7070802@virtuozzo.com \
    --to=aryabinin@virtuozzo.com \
    --cc=linux-arm-kernel@lists.infradead.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.