[Top] [All Lists]

Re: Bug in the syscall tracing code

To: Thiemo Seufer <>
Subject: Re: Bug in the syscall tracing code
From: David Daney <>
Date: Thu, 06 Oct 2005 14:13:24 -0700
Cc: "Gleb O. Raiko" <>,
In-reply-to: <20051006205308.GB31717@hattusa.textio>
Original-recipient: rfc822;
References: <> <20051006205308.GB31717@hattusa.textio>
User-agent: Mozilla Thunderbird 1.0.7-1.1.fc3 (X11/20050929)
Thiemo Seufer wrote:
Gleb O. Raiko wrote:


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.

That is the conclusion I came to in:

IIRC, k0 is already used for something.

David daney.

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