tetragon: add support to preload user strings by olsajiri · Pull Request #4489 · cilium/tetragon

olsajiri · 2026-01-08T09:25:56Z

Adding uprobe preload program to allow loading data in sleepable context. The preload program is executed before the main program loads the data and passes it via map to main program.

So far we allow only string type data to be preloaded.

netlify · 2026-01-19T22:54:42Z

✅ Deploy Preview for tetragon ready!

Name	Link
🔨 Latest commit	`e1cd620`
🔍 Latest deploy log	https://app.netlify.com/projects/tetragon/deploys/696f52de5a49940008c74608
😎 Deploy Preview	https://deploy-preview-4489--tetragon.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify project configuration.

Adding test that loads string pointer to register and will be used in following tests. Signed-off-by: Jiri Olsa <jolsa@kernel.org>

andrewstrohman · 2026-01-20T19:34:26Z

+struct {
+	__uint(type, BPF_MAP_TYPE_PERCPU_ARRAY);
+	__uint(max_entries, 1);
+	__type(key, __u32);
+	__type(value, struct preload_data);
+} sleepable_preload_heap SEC(".maps");


I don't see that this is used anywhere. I do see that process_call_heap was used.

nah I messed up the setup.. copy paste error, thanks

andrewstrohman · 2026-01-20T20:34:18Z

+
+	data = map_lookup_elem(&process_call_heap, &zero);
+	if (!data)
+		return 0;
+
+	bpf_copy_from_user_str(data, sizeof(*data), (const void *)val, 0);
+	map_update_elem(&sleepable_preload, &id, data, BPF_ANY);


I think that this is prone to a race. If after line 49, the context is preempted due to the fact that we called bpf_copy_from_user* (which can trigger a page fault) another context can overwrite what's stored in data before line 50 is executed.

I'm not sure if we can safely use BPF_MAP_TYPE_PERCPU_ARRAY for a heap in this case.

yes, you're right.. I switched to using just the hash based per process/thread, thanks

andrewstrohman · 2026-01-20T20:43:07Z

I think that it would be helpful to explicitly call out the motivation here. I think we are doing this in order to be able to page in userspace memory for the cases where we would encounter a page fault in order to access memory. As this problem is a common for reading strings, they are the first type wired to use this. Is this an accurate understanding, or am I missing the point?

andrewstrohman · 2026-01-21T00:51:11Z

Why is this for x86_64 only? Recently, I've been experimenting with reading string args. From my limited testing, I saw that page faults only happened on x86_64. (It didn't seem to happen on arm64). Will arm64 ever need this functionality?

andrewstrohman · 2026-01-21T07:06:15Z

This PR is specific to data source pt_regs. I think it would be nice to extend similar logic for string arg reading as well.

Recently, I experimented with trying to read string arguments from uprobes using the args definition (as opposed to data). I noticed on x86_64 that I couldn't do this because the string was not already paged into memory. I think this approach would fix that problem for me. I understand that we can use this patch to read string argument via the data definition, but I think it would be nice to do it with the args syntax as well. This way, they can just read string args using the same syntax that they would for kprobe hooks.

What do you think about me trying to extend this in that way?

Adding uprobe preload program to allow loading data in sleepable context. The preload program is executed before the main program loads the data and passes it via map to main program. So far we allow only string type data to be preloaded. Signed-off-by: Jiri Olsa <jolsa@kernel.org>

Adding support to attach uprobe preload program. It's attached to be executed before the main program. We also attach cleanup program that removes preloaded data from the map after the main program is executed. The preload program depends on bpf_copy_from_user_str kfunc and x86 arch. Signed-off-by: Jiri Olsa <jolsa@kernel.org>

Adding uprobe preload test that loads user space string and ensures it's loaded. Signed-off-by: Jiri Olsa <jolsa@kernel.org>

olsajiri · 2026-01-21T11:14:04Z

I think that it would be helpful to explicitly call out the motivation here. I think we are doing this in order to be able to page in userspace memory for the cases where we would encounter a page fault in order to access memory. As this problem is a common for reading strings, they are the first type wired to use this. Is this an accurate understanding, or am I missing the point?

I tried to describe that in the PR description.. so ATM we need to delegate reading from user space to sleepable program, because now we can't make the main generic sensor sleepable ... there's pending kernel change for that, so we might be able to do that in the future, but so far we need the preload bit

olsajiri · 2026-01-21T11:15:08Z

Why is this for x86_64 only? Recently, I've been experimenting with reading string args. From my limited testing, I saw that page faults only happened on x86_64. (It didn't seem to happen on arm64). Will arm64 ever need this functionality?

I'm not sure about arm, that's why I made it x86 specific, because it's problem in there AFAIK.. if you think it's needed for arm as well, it should be easy to switch on

olsajiri · 2026-01-21T11:19:13Z

This PR is specific to data source pt_regs. I think it would be nice to extend similar logic for string arg reading as well.

Recently, I experimented with trying to read string arguments from uprobes using the args definition (as opposed to data). I noticed on x86_64 that I couldn't do this because the string was not already paged into memory. I think this approach would fix that problem for me. I understand that we can use this patch to read string argument via the data definition, but I think it would be nice to do it with the args syntax as well. This way, they can just read string args using the same syntax that they would for kprobe hooks.

What do you think about me trying to extend this in that way?

sure, I added just string so far but I think we will need other types soon

as I said earlier there's pending kernel change that will allow uprobe sensor to be sleepable, but we will still need preload for old kernels ... and we should somehow make those 2 approaches co-exists together

andrewstrohman

nice!

andrewstrohman · 2026-01-21T19:05:15Z

so ATM we need to delegate reading from user space to sleepable program, because now we can't make the main generic sensor sleepable

I'm trying to confirm the motivation for making reading from user space sleepable. I think it's so we can access any memory within the user space program. Otherwise, we would not be able to access memory that hasn't been paged in before the uprobe hook point. Is this the motivation?

olsajiri · 2026-01-21T19:43:05Z

the motivation for making reading from user space sleepable. I think it's so we can access any memory within the user space program. Otherwise, we would not be able to access memory that hasn't been paged in before the uprobe hook point

yep, exactly

kkourt

LGTM, thanks!

mtardy · 2026-01-22T14:29:28Z

I'm trying to confirm the motivation for making reading from user space sleepable. I think it's so we can access any memory within the user space program. Otherwise, we would not be able to access memory that hasn't been paged in before the uprobe hook point. Is this the motivation?

this recap would have been awesome from the start to understand the motivation directly 😅

olsajiri added the release-note/minor This PR introduces a minor user-visible change label Jan 8, 2026

olsajiri force-pushed the pr/olsajiri/preload branch 5 times, most recently from c385182 to 4960b3b Compare January 9, 2026 09:49

olsajiri force-pushed the pr/olsajiri/preload branch 3 times, most recently from 35fd2f0 to 76dbe12 Compare January 19, 2026 22:54

tetragon: Add test_3 to regs-override test program

01bafaf

Adding test that loads string pointer to register and will be used in following tests. Signed-off-by: Jiri Olsa <jolsa@kernel.org>

olsajiri force-pushed the pr/olsajiri/preload branch from 76dbe12 to e1cd620 Compare January 20, 2026 10:03

olsajiri changed the title ~~Pr/olsajiri/preload~~ tetragon: add support to preload user strings Jan 20, 2026

olsajiri marked this pull request as ready for review January 20, 2026 11:36

olsajiri requested a review from a team as a code owner January 20, 2026 11:36

olsajiri requested review from ExceptionalHandler and kkourt January 20, 2026 11:36

olsajiri assigned andrewstrohman and olsajiri and unassigned andrewstrohman Jan 20, 2026

olsajiri requested a review from andrewstrohman January 20, 2026 11:36

olsajiri mentioned this pull request Jan 20, 2026

tetragon: add support for substring operators #4393

Merged

andrewstrohman reviewed Jan 20, 2026

View reviewed changes

olsajiri added 3 commits January 21, 2026 09:03

tetragon: Add uprobe preload test

fc4a53c

Adding uprobe preload test that loads user space string and ensures it's loaded. Signed-off-by: Jiri Olsa <jolsa@kernel.org>

olsajiri force-pushed the pr/olsajiri/preload branch 2 times, most recently from 396a9a9 to fc4a53c Compare January 21, 2026 10:01

andrewstrohman approved these changes Jan 21, 2026

View reviewed changes

kkourt approved these changes Jan 22, 2026

View reviewed changes

olsajiri merged commit 8323e68 into main Jan 22, 2026
52 checks passed

olsajiri deleted the pr/olsajiri/preload branch January 22, 2026 12:04

andrewstrohman mentioned this pull request Jan 27, 2026

Enable uprobe preload arg reading for "args" config and for arm64 #4546

Merged

BrewTestBot mentioned this pull request Apr 29, 2026

tetra 1.7.0 Homebrew/homebrew-core#280098

Merged

Conversation

olsajiri commented Jan 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

netlify Bot commented Jan 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

✅ Deploy Preview for tetragon ready!

Uh oh!

andrewstrohman Jan 20, 2026

Choose a reason for hiding this comment

Uh oh!

olsajiri Jan 21, 2026

Choose a reason for hiding this comment

Uh oh!

andrewstrohman Jan 20, 2026

Choose a reason for hiding this comment

Uh oh!

olsajiri Jan 21, 2026

Choose a reason for hiding this comment

Uh oh!

andrewstrohman commented Jan 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

andrewstrohman commented Jan 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

andrewstrohman commented Jan 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

olsajiri commented Jan 21, 2026

Uh oh!

olsajiri commented Jan 21, 2026

Uh oh!

olsajiri commented Jan 21, 2026

Uh oh!

andrewstrohman left a comment

Choose a reason for hiding this comment

Uh oh!

andrewstrohman commented Jan 21, 2026

Uh oh!

olsajiri commented Jan 21, 2026

Uh oh!

kkourt left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

mtardy commented Jan 22, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

olsajiri commented Jan 8, 2026 •

edited

Loading

netlify Bot commented Jan 19, 2026 •

edited

Loading

andrewstrohman commented Jan 20, 2026 •

edited

Loading

andrewstrohman commented Jan 21, 2026 •

edited

Loading

andrewstrohman commented Jan 21, 2026 •

edited

Loading