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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
