linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Puranjay Mohan <puranjay12@gmail.com>
To: Andy Chiu <andy.chiu@sifive.com>
Cc: "Björn Töpel" <bjorn@kernel.org>,
	"Paul Walmsley" <paul.walmsley@sifive.com>,
	"Palmer Dabbelt" <palmer@dabbelt.com>,
	"Albert Ou" <aou@eecs.berkeley.edu>,
	"Steven Rostedt" <rostedt@goodmis.org>,
	"Masami Hiramatsu" <mhiramat@kernel.org>,
	"Mark Rutland" <mark.rutland@arm.com>,
	"Sami Tolvanen" <samitolvanen@google.com>,
	"Guo Ren" <guoren@kernel.org>,
	"Ley Foon Tan" <leyfoon.tan@starfivetech.com>,
	"Deepak Gupta" <debug@rivosinc.com>,
	"Sia Jee Heng" <jeeheng.sia@starfivetech.com>,
	"Björn Töpel" <bjorn@rivosinc.com>,
	"Song Shuai" <suagrfillet@gmail.com>,
	"Clément Léger" <cleger@rivosinc.com>,
	"Al Viro" <viro@zeniv.linux.org.uk>,
	"Jisheng Zhang" <jszhang@kernel.org>,
	linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org,
	linux-trace-kernel@vger.kernel.org
Subject: Re: [RFC PATCH] riscv: Implement HAVE_DYNAMIC_FTRACE_WITH_CALL_OPS
Date: Fri, 8 Mar 2024 15:13:02 +0100	[thread overview]
Message-ID: <CANk7y0hdntnN8x8keDvbQPfr1LLJwRSH5BX0dyC1tvL94sqn7A@mail.gmail.com> (raw)
In-Reply-To: <CABgGipUJU_joVOjPi4WZ4JJM72zaSrCA1QUAaP8hob3+LXkS0g@mail.gmail.com>

Hi Andy,


> >
> > I don't think implementing direct calls over call ops is fruitful for
> > RISC-V because once
> > the auipc/jalr can be patched atomically, the direct call trampoline
> > is always reachable.
>
> Yes, the auipc/jalr instruction pair can be patched atomically just as
> long as their size is naturally aligned on. However, we cannot prevent
> 2 instructions from being fetched atomically :P
>
> > Solving the atomic text patching problem would be fun!! I am eager to
> > see how it will be
> > solved.
>
> I have a patch series to solve the atomic code patching issue, which I
> am about to respin [1]. The idea is to solve it with yet another layer
> of indirection. We add a 8-B aligned space at each function entry. The
> space is a pointer to the ftrace entry. During boot, each function
> entry code is updated to perform a load and then take the jump from
> the 8-B space. When ftrace is disabled, we patch the first 4B-aligned
> instruction to a jump so as to skip the ftrace entry.
>
> We are still discussing with Alex to see if we have a better way to do
> it. If not then I'd update the patchset and re-send it. There's a
> pending improvement in the series to reduce complexity. The 8-B
> aligned space can be added before the function entry (just like your
> patch).

I briefly looked at the series and it looks promising. It looks similar to
how BPF programs jump to trampolines on ARM64. If the choice has to
be made about keeping the 8-B aligned space below or above the
function entry and both choices are viable then I would prefer keeping
the 8-B space below the function entry.

I am saying this because when nops are added above the function entry
clang's kcfi[1] doesn't work properly.

Thanks,
Puranjay

[1] https://clang.llvm.org/docs/ControlFlowIntegrity.html#fsanitize-kcfi

  reply	other threads:[~2024-03-08 14:13 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-06 16:59 [RFC PATCH] riscv: Implement HAVE_DYNAMIC_FTRACE_WITH_CALL_OPS Puranjay Mohan
2024-03-06 20:35 ` Alexandre Ghiti
2024-03-06 20:38   ` Alexandre Ghiti
2024-03-07  0:17   ` Puranjay Mohan
2024-03-08  8:48     ` Andy Chiu
2024-03-11 13:56     ` [DMARC Error] " Evgenii Shatokhin
2024-03-07 19:27 ` Björn Töpel
2024-03-07 19:51   ` Puranjay Mohan
2024-03-08  9:18     ` Andy Chiu
2024-03-08 14:13       ` Puranjay Mohan [this message]
2024-03-10  1:37       ` Guo Ren
2024-03-08 10:16     ` Björn Töpel
2024-03-08 14:22       ` Puranjay Mohan
2024-03-08 15:15         ` Björn Töpel
2024-03-12 13:42   ` Mark Rutland
2024-03-13 11:23     ` Björn Töpel
2024-03-14 14:16       ` Puranjay Mohan
2024-03-14 15:07         ` Björn Töpel
2024-03-14 20:50           ` Björn Töpel
2024-03-20 16:41             ` Andy Chiu
2024-03-21  8:48               ` Björn Töpel
2024-03-21 17:39                 ` Andy Chiu
2024-03-21 18:10                   ` Björn Töpel
2024-03-25 12:50                   ` Robbin Ehn
2024-03-20 18:03           ` Mark Rutland
2024-03-21  8:58             ` Björn Töpel
2024-03-21 14:49     ` Steven Rostedt
2024-03-21 20:02     ` Steven Rostedt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CANk7y0hdntnN8x8keDvbQPfr1LLJwRSH5BX0dyC1tvL94sqn7A@mail.gmail.com \
    --to=puranjay12@gmail.com \
    --cc=andy.chiu@sifive.com \
    --cc=aou@eecs.berkeley.edu \
    --cc=bjorn@kernel.org \
    --cc=bjorn@rivosinc.com \
    --cc=cleger@rivosinc.com \
    --cc=debug@rivosinc.com \
    --cc=guoren@kernel.org \
    --cc=jeeheng.sia@starfivetech.com \
    --cc=jszhang@kernel.org \
    --cc=leyfoon.tan@starfivetech.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mhiramat@kernel.org \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=rostedt@goodmis.org \
    --cc=samitolvanen@google.com \
    --cc=suagrfillet@gmail.com \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).