linux-kernel - Re: [PATCH] riscv: keep interrupts disabled for BREAKPOINT exception

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20210408192348.1d50c588@xhacker.debian>
Date:   Thu, 8 Apr 2021 19:23:48 +0800
From:   Jisheng Zhang <Jisheng.Zhang@...aptics.com>
To:     "Maciej W. Rozycki" <macro@...am.me.uk>
Cc:     Masami Hiramatsu <mhiramat@...nel.org>,
        Jisheng Zhang <jszhang3@...l.ustc.edu.cn>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        Palmer Dabbelt <palmer@...belt.com>,
        Albert Ou <aou@...s.berkeley.edu>,
        Guo Ren <guoren@...ux.alibaba.com>,
        linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] riscv: keep interrupts disabled for BREAKPOINT
 exception

On Sat, 3 Apr 2021 20:30:53 +0200 (CEST)
"Maciej W. Rozycki" <macro@...am.me.uk> wrote:

> CAUTION: Email originated externally, do not click links or open attachments unless you recognize the sender and know the content is safe.
> 
> 
> On Thu, 1 Apr 2021, Masami Hiramatsu wrote:
> 
> > > > > Current riscv's kprobe handlers are run with both preemption and
> > > > > interrupt enabled, this violates kprobe requirements. Fix this issue
> > > > > by keeping interrupts disabled for BREAKPOINT exception.  
> > > >
> > > > Not only while the breakpoint exception but also until the end of
> > > > the single step (maybe you are using __BUG_INSN_32 ??) need to be
> > > > disable interrupts. Can this do that?
> > > >  
> > >
> > > interrupt is disabled during "single step" by kprobes_save_local_irqflag()
> > > and kprobes_restore_local_irqflag(). The code flow looks like:
> > >
> > > do_trap_break()   // for bp
> > >   kprobe_breakpoint_handler()
> > >     setup_singlestep()
> > >       kprobes_restore_local_irqflag()
> > >
> > > do_trap_break()  // for ss
> > >   kprobe_single_step_handler()
> > >     kprobes_restore_local_irqflag()  
> >
> > OK, thanks for the confirmation!  
> 
>  Is this approach guaranteed to keep interrupt handling latency low enough
> for the system not to be negatively affected, e.g. for the purpose of NTP
> timekeeping?

IMHO, interrupt latency can't be ensured if kprobes is triggered.

thanks