| Date | Thu, 21 Oct 2021 09:34:31 -0700 | From | Kees Cook <> | Subject | Re: [PATCH 15/20] signal/sparc32: Exit with a fatal signal when try_to_clear_window_buffer fails |
| |
On Wed, Oct 20, 2021 at 12:44:01PM -0500, Eric W. Biederman wrote: > The function try_to_clear_window_buffer is only called from > rtrap_32.c. After it is called the signal pending state is retested,
nit: rtrap_32.S
> and signals are handled if TIF_SIGPENDING is set. This allows > try_to_clear_window_buffer to call force_fatal_signal and then rely on > the signal being delivered to kill the process, without any danger of > returning to userspace, or otherwise using possible corrupt state on > failure.
The TIF_SIGPENDING test happens in do_notify_resume(), though I see other code before that:
... call try_to_clear_window_buffer add %sp, STACKFRAME_SZ, %o0
b signal_p ... signal_p: andcc %g2, _TIF_DO_NOTIFY_RESUME_MASK, %g0 bz,a ret_trap_continue ld [%sp + STACKFRAME_SZ + PT_PSR], %t_psr
mov %g2, %o2 mov %l6, %o1 call do_notify_resume
Will the ret_trap_continue always be skipped?
Also I see the "tp->w_saved = 0" never happens due to the "return" in try_to_clear_window_buffer. Is that okay? Only synchronize_user_stack() uses it, and that could be called in do_sigreturn(). Should the "return" be removed?
-- Kees Cook
|