| 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
| ||
|
Message-ID: <CAJF2gTTGvmtjiXdd882k9krvnO_MpNZ6qkjwxDvy=ZOyDTA3bw@mail.gmail.com>
Date: Wed, 15 Jul 2020 14:45:11 +0800
From: Guo Ren <guoren@...nel.org>
To: Masami Hiramatsu <mhiramat@...nel.org>
Cc: Palmer Dabbelt <palmerdabbelt@...gle.com>,
Paul Walmsley <paul.walmsley@...ive.com>,
Oleg Nesterov <oleg@...hat.com>,
linux-riscv <linux-riscv@...ts.infradead.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Anup Patel <anup@...infault.org>, linux-csky@...r.kernel.org,
Greentime Hu <greentime.hu@...ive.com>,
Zong Li <zong.li@...ive.com>,
Patrick Stählin <me@...ki.ch>,
Björn Töpel <bjorn.topel@...il.com>,
Guo Ren <guoren@...ux.alibaba.com>
Subject: Re: [PATCH v3 0/7] riscv: Add k/uprobe supported
On Tue, Jul 14, 2020 at 7:23 PM Masami Hiramatsu <mhiramat@...nel.org> wrote:
>
> Hi Guo,
>
> On Mon, 13 Jul 2020 23:39:15 +0000
> guoren@...nel.org wrote:
>
> > From: Guo Ren <guoren@...ux.alibaba.com>
> >
> > The patchset includes kprobe/uprobe support and some related fixups.
> > Patrick provides HAVE_REGS_AND_STACK_ACCESS_API support and some
> > kprobe's code. The framework of k/uprobe is from csky but also refers
> > to other arches'. kprobes on ftrace is also supported in the patchset.
> >
> > There is no single step exception in riscv ISA, only single-step
> > facility for jtag. See riscv-Privileged spec:
> >
> > Interrupt Exception Code-Description
> > 1 0 Reserved
> > 1 1 Supervisor software interrupt
> > 1 2–4 Reserved
> > 1 5 Supervisor timer interrupt
> > 1 6–8 Reserved
> > 1 9 Supervisor external interrupt
> > 1 10–15 Reserved
> > 1 ≥16 Available for platform use
> > 0 0 Instruction address misaligned
> > 0 1 Instruction access fault
> > 0 2 Illegal instruction
> > 0 3 Breakpoint
> > 0 4 Load address misaligned
> > 0 5 Load access fault
> > 0 6 Store/AMO address misaligned
> > 0 7 Store/AMO access fault
> > 0 8 Environment call from U-mode
> > 0 9 Environment call from S-mode
> > 0 10–11 Reserved
> > 0 12 Instruction page fault
> > 0 13 Load page fault
> > 0 14 Reserved
> > 0 15 Store/AMO page fault
> > 0 16–23 Reserved
> > 0 24–31 Available for custom use
> > 0 32–47 Reserved
> > 0 48–63 Available for custom use
> > 0 ≥64 Reserved
> >
> > No single step!
> >
> > Other arches use hardware single-step exception for k/uprobe, eg:
> > - powerpc: regs->msr |= MSR_SINGLESTEP
> > - arm/arm64: PSTATE.D for enabling software step exceptions
> > - s390: Set PER control regs, turns on single step for the given address
> > - x86: regs->flags |= X86_EFLAGS_TF
> > - csky: of course use hw single step :)
> >
> > All the above arches use a hardware single-step exception
> > mechanism to execute the instruction that was replaced with a probe
> > breakpoint. So utilize ebreak to simulate.
> >
> > Some pc related instructions couldn't be executed out of line and some
> > system/fence instructions couldn't be a trace site at all. So we give
> > out a reject list and simulate list in decode-insn.c.
> >
> > You could use uprobe to test simulate code like this:
> >
> > echo 'p:enter_current_state_one /hello:0x6e4 a0=%a0 a1=%a1' >> /sys/kernel/debug/tracing/uprobe_events
> > echo 1 > /sys/kernel/debug/tracing/events/uprobes/enable
> > /hello
> > ^C
> > cat /sys/kernel/debug/tracing/trace
> > tracer: nop
> >
> > entries-in-buffer/entries-written: 1/1 #P:1
> >
> > _-----=> irqs-off
> > / _----=> need-resched
> > | / _---=> hardirq/softirq
> > || / _--=> preempt-depth
> > ||| / delay
> > TASK-PID CPU# |||| TIMESTAMP FUNCTION
> > | | | |||| | |
> > hello-94 [000] d... 55.404242: enter_current_state_one: (0x106e4) a0=0x1 a1=0x3fffa8ada8
> >
> > Be care /hello:0x6e4 is the file offset in elf and it relate to 0x106e4
> > in memory and hello is your target elf program.
> >
> > Try kprobe like this:
> >
> > echo 'p:myprobe _do_fork dfd=%a0 filename=%a1 flags=%a2 mode=+4($stack)' > /sys/kernel/debug/tracing/kprobe_events
> > echo 'r:myretprobe _do_fork $retval' >> /sys/kernel/debug/tracing/kprobe_event
> >
> > echo 1 >/sys/kernel/debug/tracing/events/kprobes/enable
> > cat /sys/kernel/debug/tracing/trace
> > tracer: nop
> >
> > entries-in-buffer/entries-written: 2/2 #P:1
> >
> > _-----=> irqs-off
> > / _----=> need-resched
> > | / _---=> hardirq/softirq
> > || / _--=> preempt-depth
> > ||| / delay
> > TASK-PID CPU# |||| TIMESTAMP FUNCTION
> > | | | |||| | |
> > sh-92 [000] .n.. 131.804230: myprobe: (_do_fork+0x0/0x2e6) dfd=0xffffffe03929fdf8 filename=0x0 flags=0x101000 mode=0x1200000ffffffe0
> > sh-92 [000] d... 131.806607: myretprobe: (__do_sys_clone+0x70/0x82 <- _do_fork) arg1=0x5f
> > cat /sys/kernel/debug/tracing/trace
>
> Thank you for your great work!
>
> BTW, could you also run the ftracetest and boot-time smoke test on it?
> You can find it under tools/testing/selftests/ftrace, and
> CONFIG_KPROBES_SANITY_TEST.
> It will ensure that your patch is correctly ported.
CONFIG_KPROBES_SANITY_TEST passed:
[ 0.078274] NET: Registered protocol family 16
[ 0.162015] Kprobe smoke test: started
[ 0.456900] Kprobe smoke test: passed successfully
The tools/testing/selftests/ftrace cover a lot of stuff not only
kprobe, and I'll try them later to fixup in another patchset.
--
Best Regards
Guo Ren
ML: https://lore.kernel.org/linux-csky/
Powered by blists - more mailing lists