linux-mips
[Top] [All Lists]

Re: Bug in the syscall tracing code

To: "Gleb O. Raiko" <raiko@niisi.msk.ru>
Subject: Re: Bug in the syscall tracing code
From: Thiemo Seufer <ths@networkno.de>
Date: Thu, 6 Oct 2005 22:53:08 +0200
Cc: linux-mips@linux-mips.org
In-reply-to: <43455D2D.1010901@niisi.msk.ru>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <43455D2D.1010901@niisi.msk.ru>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mutt/1.5.11
Gleb O. Raiko wrote:
> Hello,
> 
> The story continues. The last fix of the syscall tracing code was wrong, 
> unfortunately. (The bug was a user could invoke any function in the 
> kernel. The fix was not to use t2 as pointer to a syscall, s0 was chosen 
> for it.) The problem we discovered is a few syscalls do SAVE_STATIC 
> (those declared as save_static_function), so s0 (which holds pointer to 
> the syscall at the time the syscall is invoked) is saved on the stack 
> overwriting a value saved from the process being traced. No wonder, s0 
> that restored on syscall exit differs from s0 saved on syscall enter.
> 
> See, arch/mips/kernel/scall32-o32.S, syscall_trace_entry, for example. 
> The rest of ABIs are the same.
> 
> There are several ways to fix this:
> 
> 1. Make syscall handling code to be close to other arches. I mean, check 
> for the trace flag first, then parse arguments and invoke a syscall.
> 
> 2. Remove save_static_functions and do SAVE_STATIC early for several 
> syscalls (yes, one big switch or its asm equivalent).
> 
> 3. Store t2 in pt_regs (it means we have to expand this structure).
> 
> 4. I know there should be yet another way.

- Use the k1 slot instead of s0 to save the function pointer.


Thiemo

<Prev in Thread] Current Thread [Next in Thread>