linux-kernel - Re: [10 PATCHES] inline functions to avoid stack overflow

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-next>] [day] [month] [year] [list]

Date:	Wed, 25 Jun 2008 08:53:10 -0400 (EDT)
From:	Mikulas Patocka <mpatocka@...hat.com>
To:	Helge Hafting <helge.hafting@...el.hist.no>
cc:	sparclinux@...r.kernel.org, linux-kernel@...r.kernel.org,
	gcc@....gnu.org
Subject: Re: [10 PATCHES] inline functions to avoid stack overflow

On Wed, 25 Jun 2008, Helge Hafting wrote:

> Mikulas Patocka wrote:
>> Hi
>> 
>> Here I'm sending 10 patches to inline various functions.
>> 
>> To give you some understanding of sparc64, every function there uses big 
>> stack frame (at least 192 bytes). 128 bytes are required by architecture 
>> (16 64-bit registers), 48 bytes are there due to mistake of Sparc64 ABI 
>> designers (calling function has to allocate 48 bytes for called function) 
>> and 16 bytes are some dubious padding.
> I guess there is no way around those 128 bytes required by hardware - but
> is it necessary to allocate the 48 bytes of "mistake" and the dubious 
> padding?
>
> Linux kernel functions don't call any outside functions, and are not called 
> from
> outside either. So violating the ABI should be ok - there is nothing else to
> be compatible to. Similiar to how x86 experimented with --mregparm to get
> a little more performance from changing the kernel calling convention. 
> Helge Hafting

So, ask gcc developers to do kernel-specific ABI with only 128-byte stack 
frame.

BTW. could some gcc developer explain the reason for additional 16-bytes 
on stack on sparc64? 64-bit ABI mandates 176 bytes, but gcc allocates 192 
bytes.

Even worse, gcc doesn't use these additional bytes. If you try this:

extern void f(int *i);
void g()
{
         int a;
         f(&a);
}

, it allocates additional 16 bytes for the variable "a" (so there's total 
208 bytes), even though it could place the variable into 48-byte 
ABI-mandated area that it inherited from the caller or into it's own 
16-byte padding that it made when calling "f".

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