> I found it extremely difficult to trigger the race condition without the > articifial test - arch_ptrace_stop() only sleeps if the user page is not > present, but in the common case the register stack backing store will > have been quite recently accessed by the process. It is supposed to be a rare race, after all. :-) We're just being thorough to cover it, not that it ever actually happened in practice or was expected to. > It should be possible to create a large file, flush the page cache, put > the RSE into lazy mode, flush it and map the register stack from that > file, so that no memory accesses to the backing store are done before > ptrace_stop(), but for the time being I placed an msleep(100) after > arch_ptrace_stop(). And then make the file so mapped be from a broken NFS or FUSE or somesuch mount that actually blocks forever on the fault. That would be the probable style of a DoS attack exploiting this to create unkillable processes. > Anyway, I produced a test case which succeeds when the call to > sigkill_pending() is in and fails when it's commented out. I'm attaching > it here (the kernel patch to follow). Ok! It sounds like we've verified all the pieces of the fix. There's one more wrinkle that I've remembered. A traced process has not necessarily gone through ptrace_stop when you do ptrace on it, though normally so. It can be in job control stop (TASK_STOPPED), such as when you attach gdb to something stopped by ^Z. To cover that case, the easiest thing I can see is to define an arch_ptrace_attach macro that does the writeback. This requires making the ia64_rse_writeback function (or whatever it's to be called) work on either current or another task that's stopped. i.e. #define arch_ptrace_attach(child) \ do if (!test_tsk_thread_flag(child, TIF_RESTORE_RSE) && \ ptrace_check_attach(child, 0) == 0) \ ia64_writeback_rse(child); \ while (0) Thanks, Roland - To unsubscribe from this list: send the line "unsubscribe linux-ia64" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
|