Skip to content

Add fprobe support#16

Open
scosu wants to merge 6 commits intoCHERI-Alliance:codasip-cheri-riscv-6.18from
scosu:topic/tracing/v6.18
Open

Add fprobe support#16
scosu wants to merge 6 commits intoCHERI-Alliance:codasip-cheri-riscv-6.18from
scosu:topic/tracing/v6.18

Conversation

@scosu
Copy link
Copy Markdown

@scosu scosu commented Mar 24, 2026

This series transforms pointers that are used afterwards to uintptr_t and keeps the ones that are not used as unsigned long. We are not able to use the compacted fprobe header as we would loose the capabilities.

See the individual commits for details about what is done why.

Note: No userspace modifications are required. trace-cmd works well when installed.

scosu added 6 commits March 20, 2026 12:02
fp pointer and unsigned long are both aligned and don't need the
__packed keyword. Remove it to make it compile for CHERI.

Signed-off-by: Markus Schneider-Pargmann (The Capable Hub) <msp@baylibre.com>
The header encoding packs the data into one unsigned long on 64 bit
architectures. However this doesn't work for CHERI as we need the
capabilities and would loose them through unsigned long conversions.

Signed-off-by: Markus Schneider-Pargmann (The Capable Hub) <msp@baylibre.com>
Only use the address for hashing in the fprobe_ip_table by using
__c_fakep(). The capabilities are not needed here.

Signed-off-by: Markus Schneider-Pargmann (The Capable Hub) <msp@baylibre.com>
Many uses of unsigned long need to be converted to uintptr_t where these
may be used as a pointer afterwards.

Signed-off-by: Markus Schneider-Pargmann (The Capable Hub) <msp@baylibre.com>
If we want to use the pointer after adding the offset we need to keep
the capabilities. Converting to unsigned long would discard the
capabilities. Use a char pointer instead to add the offset.

Signed-off-by: Markus Schneider-Pargmann (The Capable Hub) <msp@baylibre.com>
Use __c_fakep() to print pointers. The capability is not required here
anymore.

Signed-off-by: Markus Schneider-Pargmann (The Capable Hub) <msp@baylibre.com>
@martin-kaiser
Copy link
Copy Markdown

Hi Markus,

we've already updated fprobes for cheri in our Codasip tree.
At the moment, we're working on the userspace interface for fprobes and we're planning to update the other probes next.

It looks like we need better coordination to avoid duplicate work. Unfortunately, I'm not at Cheri Blossom but I'll have a word with my colleagues who are attending.

Best regards,
Martin

@scosu
Copy link
Copy Markdown
Author

scosu commented Mar 25, 2026

Hi Martin,

do you have code for kprobes already? I am currently working on that.

Also I am curious on what userspace interface you are working on for fprobes? I tested and used trace-cmd which worked well.

Best
Markus

@pzalewski-thegoodpenguin
Copy link
Copy Markdown

Hi all,

Indeed, the work could be synced a bit better - but ideally not done in private at all.
I think this would be a good case for Co-developed-by ? @carlrobshaw

@martin-kaiser
Copy link
Copy Markdown

My understanding is that is was discussed and agreed within the capable hub that Codasip are working on the tracing subsystem.

We should really clarify this in tomorrow's call....

@pzalewski-thegoodpenguin
Copy link
Copy Markdown

And mine was different, we did say we do work on that on WG meetings, no harm done really but from now on we shall create an issue in github and work on that issue. Ideally we would all do this here, so all devs had visibility on what is being currently worked on.

struct __fprobe_header {
struct fprobe *fp;
unsigned long size_words;
} __packed;
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

packed_if_not_cheri

#include <linux/bits.h>

#ifdef CONFIG_64BIT
#if defined(CONFIG_64BIT) && !defined(__CHERI__)
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

for arm morello, the kernel does not use capabilities, only userspace does
the packing would work in this case

why not disable this in the arch part (that's what I've done)?

fbuffer.regs = ftrace_get_regs(fregs);
entry = fbuffer.entry = ring_buffer_event_data(fbuffer.event);
entry->func = entry_ip;
entry->ret_ip = ret_ip;
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

struct fexit_trace_entry_head goes into the ringbuffer. for cheri ftrace, the ringbuffer does not store capabilities.
the components for fexit_trace_entry_head must be ptraddr_t - and we need __c_ua(ret_ip) here

break;
case FETCH_OP_EDATA:
val = *(unsigned long *)((unsigned long)edata + code->offset);
val = *(unsigned long *)((char *)edata + code->offset);
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why not (uintptr_t)edata?

@martin-kaiser
Copy link
Copy Markdown

for cheri ftrace, the shadow stack is a uintptr_t array (it stores a return address capability)
the calculations for the private data area (fgraph_reserve_data) have to take this into account

@martin-kaiser
Copy link
Copy Markdown

And mine was different, we did say we do work on that on WG meetings, no harm done really but from now on we shall create an issue in github and work on that issue. Ideally we would all do this here, so all devs had visibility on what is being currently worked on.

Ok, this makes sense. I've just created an issue for the work on probes.

@pzalewski-thegoodpenguin
Copy link
Copy Markdown

And mine was different, we did say we do work on that on WG meetings, no harm done really but from now on we shall create an issue in github and work on that issue. Ideally we would all do this here, so all devs had visibility on what is being currently worked on.

Ok, this makes sense. I've just created an issue for the work on probes.

Excellent thanks !

@martin-kaiser
Copy link
Copy Markdown

Hi Martin,

do you have code for kprobes already? I am currently working on that.

Also I am curious on what userspace interface you are working on for fprobes? I tested and used trace-cmd which worked well.

By userspace interface I mean the config strings you can write to /sys/kernel/tracing/dynamic_event. I'm sure that the basics are working for you, but we have to go through all combinations. E.g. there's a parameter to read from an arbitrary memory address. I can't imagine that this works out of the box without fabricating a capability (at least for me it didn't).

And even if everything was working, we could add a capability type to the fetch data types ;-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants