From: Jakub Jelinek <jakub@redhat.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: pageexec@freemail.hu, Sam Ravnborg <sam@ravnborg.org>,
Arjan van de Ven <arjan@infradead.org>,
linux-kernel@vger.kernel.org, torvalds@linux-foundation.org,
Thomas Gleixner <tglx@linutronix.de>,
"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [x86.git#mm] stack protector fixes, vmsplice exploit
Date: Thu, 14 Feb 2008 17:35:53 -0500 [thread overview]
Message-ID: <20080214223553.GW24887@devserv.devel.redhat.com> (raw)
In-Reply-To: <20080214202535.GA25316@elte.hu>
On Thu, Feb 14, 2008 at 09:25:35PM +0100, Ingo Molnar wrote:
> The per function call overhead from stackprotector is already pretty
> serious IMO, but at least that's something that GCC _could_ be doing
> (much) smarter (why doesnt it jne forward out to __check_stk_failure,
> instead of generating 4 instructions, one of them a default-mispredicted
> branch instruction??), so that overhead could in theory be something
> like 4 fall-through instructions per function, instead of the current 6.
Where do you see a mispredicted branch?
int foo (void)
{
char buf[64];
bar (buf);
return 6;
}
-O2 -fstack-protector -m64:
subq $88, %rsp
movq %fs:40, %rax
movq %rax, 72(%rsp)
xorl %eax, %eax
movq %rsp, %rdi
call bar
movq 72(%rsp), %rdx
xorq %fs:40, %rdx
movl $6, %eax
jne .L5
addq $88, %rsp
ret
.L5:
.p2align 4,,6
.p2align 3
call __stack_chk_fail
-O2 -fstack-protector -m32:
pushl %ebp
movl %esp, %ebp
subl $88, %esp
movl %gs:20, %eax
movl %eax, -4(%ebp)
xorl %eax, %eax
leal -68(%ebp), %eax
movl %eax, (%esp)
call bar
movl $6, %eax
movl -4(%ebp), %edx
xorl %gs:20, %edx
jne .L5
leave
ret
.L5:
.p2align 4,,7
.p2align 3
call __stack_chk_fail
-O2 -fstack-protector -m64 -mcmodel=kernel:
subq $88, %rsp
movq %gs:40, %rax
movq %rax, 72(%rsp)
xorl %eax, %eax
movq %rsp, %rdi
call bar
movq 72(%rsp), %rdx
xorq %gs:40, %rdx
movl $6, %eax
jne .L5
addq $88, %rsp
ret
.L5:
.p2align 4,,6
.p2align 3
call __stack_chk_fail
both with gcc 4.1.x and 4.3.0.
BTW, you can use -fstack-protector --param=ssp-buffer-size=4
etc. to tweak the size of buffers to trigger stack protection, the
default is 8, but e.g. whole Fedora is compiled with 4.
Jakub
next prev parent reply other threads:[~2008-02-14 22:36 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-14 17:00 [x86.git#mm] stack protector fixes, vmsplice exploit Ingo Molnar
2008-02-14 17:16 ` pageexec
2008-02-14 19:00 ` Ingo Molnar
2008-02-14 18:55 ` pageexec
2008-02-14 20:25 ` Ingo Molnar
2008-02-14 21:00 ` Arjan van de Ven
2008-02-14 21:12 ` pageexec
2008-02-14 22:35 ` Jakub Jelinek [this message]
2008-02-14 21:43 ` pageexec
2008-02-14 23:19 ` Ingo Molnar
2008-02-14 23:16 ` Ingo Molnar
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=20080214223553.GW24887@devserv.devel.redhat.com \
--to=jakub@redhat.com \
--cc=arjan@infradead.org \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=pageexec@freemail.hu \
--cc=sam@ravnborg.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox