linux-kernel - Re: [PATCH] arm64: fix add kasan bug

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]

Date:	Wed, 6 Jan 2016 00:17:17 +0300
From:	Andrey Ryabinin <ryabinin.a.a@...il.com>
To:	Catalin Marinas <catalin.marinas@....com>
Cc:	zhongjiang <zhongjiang@...wei.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	"qiuxishi@...wei.com" <qiuxishi@...wei.com>,
	"long.wanglong@...wei.com" <long.wanglong@...wei.com>,
	Will Deacon <will.deacon@....com>
Subject: Re: [PATCH] arm64: fix add kasan bug

2016-01-05 13:10 GMT+03:00 Catalin Marinas <catalin.marinas@....com>:
> On Thu, Dec 31, 2015 at 10:09:09AM +0000, zhongjiang wrote:
>> From: zhong jiang <zhongjiang@...wei.com>
>>
>> In general, each process have 16kb stack space to use, but
>> stack need extra space to store red_zone when kasan enable.
>> the patch fix above question.
>>
>> Signed-off-by: zhong jiang <zhongjiang@...wei.com>
>> ---
>>  arch/arm64/include/asm/thread_info.h | 15 +++++++++++++--
>>  1 file changed, 13 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm64/include/asm/thread_info.h b/arch/arm64/include/asm/thread_info.h
>> index 90c7ff2..45b5a7e 100644
>> --- a/arch/arm64/include/asm/thread_info.h
>> +++ b/arch/arm64/include/asm/thread_info.h
> [...]
>> +#ifdef CONFIG_KASAN
>> +#define THREAD_SIZE          32768
>> +#else
>>  #define THREAD_SIZE          16384
>> +#endif
>
> I'm not really keen on increasing the stack size to 32KB when KASan is
> enabled (that's 8 4K pages). Have you actually seen a real problem with
> the default size?

> How large is the red_zone?
>

Typical stack frame layout looks like this:
    | 32-byte redzone | variable-1| padding-redzone to the next
32-byte boundary| variable-2|padding |.... | 32-byte redzone|

AFAIK gcc creates redzones  only if it can't prove that all accesses
to variable are valid (e.g. reference to variable passed to external
function).
Besides redzones, stack could be increased due to additional spilling.
Although arm64 should be less affected by this since it has more
registers than x86_64.
On x86_64 I've seen few bad cases where stack frame of a single
function was bloated up to 6K.


> With 4.5 we are going for separate IRQ stack on arm64, so the typical
> stack overflow case no longer exists.
>
> --
> Catalin
--
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/