[lkml]   [2008]   [Feb]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [x86.git#mm] stack protector fixes, vmsplice exploit
    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 ;-).

     \ /
      Last update: 2008-02-14 19:19    [W:0.025 / U:15.512 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site