linux-kernel - Re: XFS stack overhead

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, 21 Oct 2009 16:22:31 -0400
From:	Chuck Ebbert <cebbert@...hat.com>
To:	Eric Sandeen <sandeen@...hat.com>
Cc:	Ingo Molnar <mingo@...e.hu>,
	Arjan van de Ven <arjan@...radead.org>,
	Dave Jones <davej@...hat.com>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>, esandeen@...hat.com,
	"H. Peter Anvin" <hpa@...or.com>
Subject: Re: XFS stack overhead

On Wed, 21 Oct 2009 14:21:54 -0500
Eric Sandeen <sandeen@...hat.com> wrote:

> > Also, the posting apparently mixes 'stack overhead' with 'runtime 
> > overhead'.
> 
> right, that's why I asked, I'm not sure if stackprotector has runtime
> overhead as well.
> 

A bigger stack causes runtime overhead too because it increases the cache
footprint of the workload.

For the function I looked at the insn overhead was substantial:

On entry:
ffffffff8113ffa0:       48 83 ec 10             sub    $0x10,%rsp
...
ffffffff8113ffa9:       65 48 8b 04 25 28 00    mov    %gs:0x28,%rax
ffffffff8113ffb0:       00 00
ffffffff8113ffb2:       48 89 45 f8             mov    %rax,-0x8(%rbp)

On exit:
ffffffff81140000:       48 8b 55 f8             mov    -0x8(%rbp),%rdx
ffffffff81140004:       65 48 33 14 25 28 00    xor    %gs:0x28,%rdx
ffffffff8114000b:       00 00
ffffffff8114000d:       74 13                   je     ffffffff81140022 <mem_cgroup_get_reclaim_stat_from_page+0x86>
...
ffffffff8114001d:       e8 ef 42 f2 ff          callq  ffffffff81064311 <__stack_chk_fail>

So that's 37 extra bytes of code: 1 subtract, 4 reg/mem moves, an xor
and a conditional jump that always get executed -- on every function
call.

And all that, in this case, for a function that doesn't even have any
on-stack variables and can hardly be expected to be vulnerable to
stack-smashing attacks.
--
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/