LKML Archive on
help / color / mirror / Atom feed
To: Ingo Molnar <>
Cc: Sam Ravnborg <>,
	Arjan van de Ven <>,,,
	Thomas Gleixner <>,
	"H. Peter Anvin" <>
Subject: Re: [x86.git#mm] stack protector fixes, vmsplice exploit
Date: Thu, 14 Feb 2008 19:16:20 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On 14 Feb 2008 at 18:00, Ingo Molnar wrote:

some comments:

>   x86: fix execve with -fstack-protect

the commit comment says:

> This hack was true up to the point the stackprotector added
> another word to the stack frame. Shifting all the addresses
> by 8 bytes, crashing and burning any exec attempt.

actually, that's not the problem here because the canary is in the
local variable area, it doesn't affect the passed arguments. what
happens here is that gcc treats the argument area as owned by the
callee, not the caller and is allowed to do certain tricks. for ssp
it will make a copy of the struct passed by value into the local
variable area and pass *its* address down, and it won't copy it back
into the original instance stored in the argument area.

so once sys_execve returns, the pt_regs passed by value hasn't at all
changed and its default content will cause a nice double fault (FWIW,
this part took me the longest to debug, being down with cold didn't
help it either ;).

>   x86: fix stackprotector canary updates during context switches

the commit says:

> Note: this means that we call __switch_to() [and its sub-functions]
> still with the old canary, but that is not a problem, both the previous
> and the next task has a high-quality canary. The only (mostly academic)
> disadvantage is that the canary of one task may leak onto the stack of
> another task, increasing the risk of information leaks, were an attacker
> able to read the stack of specific tasks (but not that of others).

the best practical defense against leaking the canary is to change its
value on every syscall but it has some performance impact in microbenchmarks.

>   x86: stackprotector: mix TSC to the boot canary

this should probably be implemented in a general get_random_long()

>   x86: test the presence of the stackprotector
>   x86: streamline stackprotector

the config comment says -fstack-protector whereas you're really enabling
the stonger -fstack-protector-all feature (without the latter the ssp
test function sample_stackprotector_fn wouldn't even be instrumented ;-).

  reply	other threads:[~2008-02-14 18:17 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-14 17:00 Ingo Molnar
2008-02-14 17:16 ` pageexec [this message]
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
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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \
    --subject='Re: [x86.git#mm] stack protector fixes, vmsplice exploit' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).