From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id EC69FC07E99 for ; Mon, 5 Jul 2021 14:40:19 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C6A4B61959 for ; Mon, 5 Jul 2021 14:40:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231420AbhGEOmz (ORCPT ); Mon, 5 Jul 2021 10:42:55 -0400 Received: from mail.kernel.org ([198.145.29.99]:44982 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230504AbhGEOmz (ORCPT ); Mon, 5 Jul 2021 10:42:55 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id BBDA16195E; Mon, 5 Jul 2021 14:40:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1625496018; bh=ZdnvFTKPNqMYGq5RT15Z4gJxdJYehJ1cRy+yS+OH5bM=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=hk4e4xRPtsJahAiWKdJey/x8nyohKetkvaYP3y14vHjX1VnoEO1TxKZq8jOr1EdE5 FMgmZ90/EzBuusZbCjtR7HColKmiHHNOugA9np1+eradUX0TPgdg5iHYkOdPOYN7LA ITb06PDjGIX7DJ6NHFnt8GJveCYzYbalAZMMaubNeOilTKhTai8XjynyLUTMwa1MOV k2Bz4C3YxglmEZG/QWQ9kd3sCI7kq8eh73ctPKZuGKxYJkPiWvY0L0pfR4b9OnLTOM NwwIKS+pkDJI+tUbbOFebT6I4hGRrmFnr1g+TsxZKJtbZ4B7JHpUJ+hywEXUYrb0d9 RwloBPYVGbsYQ== Date: Mon, 5 Jul 2021 23:40:14 +0900 From: Masami Hiramatsu To: Ingo Molnar Cc: Steven Rostedt , Josh Poimboeuf , X86 ML , Daniel Xu , linux-kernel@vger.kernel.org, bpf@vger.kernel.org, kuba@kernel.org, mingo@redhat.com, ast@kernel.org, Thomas Gleixner , Borislav Petkov , Peter Zijlstra , kernel-team@fb.com, yhs@fb.com, linux-ia64@vger.kernel.org, Abhishek Sagar , Andrii Nakryiko Subject: Re: [PATCH -tip v8 08/13] arm: kprobes: Make a space for regs->ARM_pc at kretprobe_trampoline Message-Id: <20210705234014.4e0a9ec6a60ef2db5ff93819@kernel.org> In-Reply-To: References: <162399992186.506599.8457763707951687195.stgit@devnote2> <162399999702.506599.16339931387573094059.stgit@devnote2> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org On Mon, 5 Jul 2021 10:04:41 +0200 Ingo Molnar wrote: > > * Masami Hiramatsu wrote: > > > Change kretprobe_trampoline to make a space for regs->ARM_pc so that > > kretprobe_trampoline_handler can call instruction_pointer_set() > > safely. > > The idiom is "make space", but in any case, what does this mean? Since arm's kretprobe_trampoline() saves partial pt_regs, regs->ARM_pc is not accessible (it points the caller function's stack frame). Therefore, this extends the stack frame for storing regs->ARM_pc. > > Was the stack frame set up in kretprobe_trampoline() and calling > trampoline_handler() buggy? > > If yes, then explain the bad effects of the bug, and make all of this clear > in the title & changelog. This is actually buggy from the specification viewpoint. And if the kretprobe handler sets the instruction pointer, it must be ignored, but in reallty, it breaks the stack frame (this does not happen in the ftrace/perf dynamic events, but a custom kretprobe kernel module can do this.) Thank you, > > Thanks, > > Ingo -- Masami Hiramatsu