linux-kernel - Re: [PATCH] RISC-V: Don't check text_mutex during stop

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20210528182102.19319b1b@gandalf.local.home>
Date:   Fri, 28 May 2021 18:21:02 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Palmer Dabbelt <palmer@...belt.com>
Cc:     linux-riscv@...ts.infradead.org, mingo@...hat.com,
        Paul Walmsley <paul.walmsley@...ive.com>,
        aou@...s.berkeley.edu, mhiramat@...nel.org, zong.li@...ive.com,
        guoren@...ux.alibaba.com, Atish Patra <Atish.Patra@....com>,
        linux-kernel@...r.kernel.org, kernel-team@...roid.com,
        changbin.du@...il.com
Subject: Re: [PATCH] RISC-V: Don't check text_mutex during stop_machine

On Sat, 22 May 2021 12:32:05 -0700 (PDT)
Palmer Dabbelt <palmer@...belt.com> wrote:

> we can then IPI to all the harts in order to get them on the same page 
> about that trap, which we can then skip over.  We'll need some way to 
> differentiate this from accidental executions of unimp, but we can just 
> build up a table somewhere (it wasn't immediately clear how x86 does 

It currently uses the same code as the text_poke does, which does a
"batching" and keeps track of the locations that were modified. But before
that change (768ae4406a x86/ftrace: Use text_poke()), it had:

int ftrace_int3_handler(struct pt_regs *regs)
{
        unsigned long ip;

        if (WARN_ON_ONCE(!regs))
                return 0;

        ip = regs->ip - INT3_INSN_SIZE;

        if (ftrace_location(ip)) {
                int3_emulate_call(regs, (unsigned long)ftrace_regs_caller);
                return 1;
        } else if (is_ftrace_caller(ip)) {
                if (!ftrace_update_func_call) {
                        int3_emulate_jmp(regs, ip + CALL_INSN_SIZE);
                        return 1;
                }
                int3_emulate_call(regs, ftrace_update_func_call);
                return 1;
        }

        return 0;
}

That "ftrace_location()" is the table you are looking for. It will return
true if the location is registered with ftrace or not (i.e. the mcount
call).

The "int3_emulate_jmp()" is needed to handle the case that we switch from
one trampoline to another trampoline. But that's also an architecture
specific feature, and RISC-V may not have that yet.


-- Steve


> this).  Then we have no ordering restrictions on converting the rest of 
> the stub into what's necessary to trace a function, which should look 
> the same as what we have now