kernel-hardening - Re: [PATCH 1/1] stackleak: Disable ftrace for stackleak.c

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Mon, 12 Nov 2018 19:51:00 +0300
From: Alexander Popov <alex.popov@...ux.com>
To: Masami Hiramatsu <mhiramat@...nel.org>,
 Steven Rostedt <rostedt@...dmis.org>
Cc: kernel-hardening@...ts.openwall.com, Kees Cook <keescook@...omium.org>,
 Jann Horn <jannh@...gle.com>, Ingo Molnar <mingo@...nel.org>,
 Andy Lutomirski <luto@...nel.org>, Joerg Roedel <joro@...tes.org>,
 Borislav Petkov <bp@...en8.de>, Thomas Gleixner <tglx@...utronix.de>,
 Dave Hansen <dave.hansen@...ux.intel.com>,
 Peter Zijlstra <peterz@...radead.org>, Jan Kara <jack@...e.cz>,
 Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
 Dan Williams <dan.j.williams@...el.com>,
 Masahiro Yamada <yamada.masahiro@...ionext.com>, x86@...nel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/1] stackleak: Disable ftrace for stackleak.c

Hello Steven and Masami,

Thanks for your comments.

On 12.11.2018 5:50, Masami Hiramatsu wrote:
> Hi Alexander and Steve,
> 
> On Sun, 11 Nov 2018 20:53:51 -0500
> Steven Rostedt <rostedt@...dmis.org> wrote:
> 
>> On Sun, 11 Nov 2018 13:19:45 +0300
>> Alexander Popov <alex.popov@...ux.com> wrote:
>>
>>> On 11.11.2018 2:30, Steven Rostedt wrote:
>>>> On Sun, 11 Nov 2018 01:05:30 +0300
>>>> Alexander Popov <alex.popov@...ux.com> wrote:
>>>>   
>>>>> The stackleak_erase() function is called on the trampoline stack at the
>>>>> end of syscall. This stack is not big enough for ftrace operations,
>>>>> e.g. it can be overflowed if we enable kprobe_events for stackleak_erase().  
>>>>
>>>> Is the issue with kprobes or with function tracing? Because this stops
>>>> function tracing which I only want disabled if function tracing itself
>>>> is an issue, not for other things that may use the function tracing
>>>> infrastructure.  
>>>
>>> Hello Steven,
>>>
>>> I believe that stackleak erasing is not compatible with function tracing itself.
>>> That's what the kernel testing robot has hit:
>>> https://www.openwall.com/lists/kernel-hardening/2018/11/09/1
>>>
>>> I used kprobe_events just to reproduce the problem:
>>> https://www.openwall.com/lists/kernel-hardening/2018/11/09/4
>>
>> Have you tried adding a "notrace" to stackleak_erase()?
>>
>> Not tracing the entire file is a bit of overkill. There's no reason
>> ftrace can't trace stack_erasing_sysctl() or perhaps even
>> stackleak_track_stack() as that may be very interesting to trace.

Yes, thank you. It's much better.

> I think it is not enough for stopping kprobes. If you want to stop the kprobes
> (int3 version) on stackleak_erase(), you should use NOKPROBE_SYMBOL(stackleak_erase),
> since kprobes can work without ftrace. 

Thanks!

I learned how to use kprobes without ftrace and managed to reproduce the problem
as well (I modified kprobe_example.c and kretprobe_example.c). NOKPROBE_SYMBOL()
allowed to avoid it.

I'll send the patch soon.

By the way, are there any other tracing/instrumentation mechanisms that should
be disabled?

Best regards,
Alexander

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.