From: pageexec@freemail.hu
To: Ingo Molnar <mingo@elte.hu>
Date: Thu, 14 Feb 2008 19:16:20 +0200
MIME-Version: 1.0
Subject: Re: [x86.git#mm] stack protector fixes, vmsplice exploit
Reply-to: pageexec@freemail.hu
CC: 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>
Message-ID: <47B49384.23437.F8FB16A@pageexec.freemail.hu>
In-reply-to: <20080214170058.GA2043@elte.hu>
References: <20080214170058.GA2043@elte.hu>
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Content-description: Mail message body
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2346
Lines: 56

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()
function...

>   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 ;-).

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/