Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Don't unpack kernel headers or look in tmp #3156

Merged
merged 1 commit into from May 15, 2024

Conversation

jordalgo
Copy link
Contributor

@jordalgo jordalgo commented May 7, 2024

Looking in shared writeable locations for kernel
headers is inherently risky even bpftrace does
the unpacking. Remove this functionality and let
the user specify the path to these headers if
we can't find them in known locations.

References:
#3033
#3154

Checklist
  • Language changes are updated in man/adoc/bpftrace.adoc
  • User-visible and non-trivial changes updated in CHANGELOG.md
  • The new behaviour is covered by tests

@jordalgo
Copy link
Contributor Author

jordalgo commented May 10, 2024

Do we need another patch release after we land this? Considering I didn't really fix the problem before. cc @danobi

@viktormalik
Copy link
Contributor

Do we need another patch release after we land this? Considering I didn't really fix the problem before. cc @danobi

I would prefer that. Since it's a CVE, it'd make the life of us distro packagers easier.

FWIW, I think that we should also do a regular release soon, preferably with this merged.

Comment on lines +730 to +737
LOG(WARNING) << "Could not find kernel headers in " << ksrc << " or "
<< kobj
<< ". To specify a particular path to kernel headers, set the "
"env variables BPFTRACE_KERNEL_SOURCE and, optionally, "
"BPFTRACE_KERNEL_BUILD if the kernel was built in a "
"different directory than its source. To create kernel "
"headers run 'modprobe kheaders', which will create a tar "
"file at /sys/kernel/kheaders.tar.xz";
Copy link
Contributor

Choose a reason for hiding this comment

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

I imagine that in most cases bpftrace doesn't need kheaders (can use BTF data instead); would it make sense to only print this warning if kernel headers end up being required?

A couple of cases come to mind:

  • Bpftrace script unconditionally includes one or more kernel headers (e.g. #include <linux/sched.h> without gating on BPFTRACE_HAVE_BTF)
  • Conflicts between user-defined and BTF types

Related: commit 91db77c5

cc @danobi

Copy link
Contributor

Choose a reason for hiding this comment

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

This is a good point. I agree that we should not print the warning by default as there's a number of situations where kheaders are not necessary.

Copy link
Contributor Author

@jordalgo jordalgo May 13, 2024

Choose a reason for hiding this comment

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

How about as a stop-gap (in the interest of getting this patched), I just reinstate the !bpftrace.feature_->has_btf() check as a conditional to show the warning?

Copy link
Contributor

Choose a reason for hiding this comment

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

I may remember it wrong (it's been a while since I wrote that code) but IMHO kheaders are needed iff ClangParser runs so we should use the same condition as in clang_parser.cpp:663:

  if (program->c_definitions.empty() && bpftrace.btf_set_.empty())

It'd be nice if we could reuse it.

An alternative would be to issue the warning from ClangParser when it fails but that may be even more complicated.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I moved a few things around but I'm using this same check before even calling get_kernel_dirs so the warning should only be shown in that case.

@jordalgo jordalgo force-pushed the kheaders branch 2 times, most recently from df6a68f to 1730a16 Compare May 13, 2024 17:58
Looking in shared writeable locations for kernel
headers is inherently risky even bpftrace does
the unpacking. Remove this functionality and let
the user specify the path to these headers if
we can't find them in known locations.

References:
bpftrace#3033
bpftrace#3154
@@ -660,9 +660,6 @@ bool ClangParser::parse(ast::Program *program,
StderrSilencer silencer;
silencer.silence();
#endif
if (program->c_definitions.empty() && bpftrace.btf_set_.empty())
Copy link
Contributor Author

Choose a reason for hiding this comment

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

moved this into main

Copy link
Contributor

@viktormalik viktormalik left a comment

Choose a reason for hiding this comment

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

Nice, I like this approach.

Technically speaking, ClangParser may run successfully without kheaders (e.g. when user only defines custom types) but I'm ok with issuing a warning for the sake of fixing this. In most cases, BTF is present and so no warning will be shown.

@jordalgo
Copy link
Contributor Author

ClangParser may run successfully without kheaders (e.g. when user only defines custom types)

Ah ok, do we have a way to check for this already?

@viktormalik
Copy link
Contributor

ClangParser may run successfully without kheaders (e.g. when user only defines custom types)

Ah ok, do we have a way to check for this already?

I don't think so.

@jordalgo
Copy link
Contributor Author

Ok, gonna merge in a few hours unless there are any objections.

@jordalgo jordalgo merged commit bc73244 into bpftrace:master May 15, 2024
18 checks passed
viktormalik pushed a commit to viktormalik/bpftrace that referenced this pull request May 20, 2024
Looking in shared writeable locations for kernel
headers is inherently risky even bpftrace does
the unpacking. Remove this functionality and let
the user specify the path to these headers if
we can't find them in known locations.

References:
bpftrace#3033
bpftrace#3154

Co-authored-by: Jordan Rome <jordalgo@fedoraproject.org>
@viktormalik viktormalik mentioned this pull request May 20, 2024
3 tasks
@viktormalik
Copy link
Contributor

@jordalgo I did a backport to bpftrace 0.20.x in #3190.

viktormalik added a commit to viktormalik/bpftrace that referenced this pull request May 20, 2024
Commit 14cb69d added the "/bpftrace/include" prefix to headers
generated by bpftrace (__btf_generated_header.h, clang_workarounds.h),
however commit bc73244 ("Don't unpack kernel headers or look in tmp
(bpftrace#3156)") broke the latter when moving around code in main.cpp.

Reintroduce the prefix.
viktormalik added a commit to viktormalik/bpftrace that referenced this pull request May 20, 2024
Commit 14cb69d added the "/bpftrace/include" prefix to headers
generated by bpftrace (__btf_generated_header.h, clang_workarounds.h),
however, commit bc73244 ("Don't unpack kernel headers or look in tmp
(bpftrace#3156)") broke the latter when moving code around in main.cpp.

Reintroduce the prefix.
viktormalik added a commit that referenced this pull request May 21, 2024
Commit 14cb69d added the "/bpftrace/include" prefix to headers
generated by bpftrace (__btf_generated_header.h, clang_workarounds.h),
however, commit bc73244 ("Don't unpack kernel headers or look in tmp
(#3156)") broke the latter when moving code around in main.cpp.

Reintroduce the prefix.
viktormalik pushed a commit that referenced this pull request May 21, 2024
Looking in shared writeable locations for kernel
headers is inherently risky even bpftrace does
the unpacking. Remove this functionality and let
the user specify the path to these headers if
we can't find them in known locations.

References:
#3033
#3154

Co-authored-by: Jordan Rome <jordalgo@fedoraproject.org>
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.

None yet

3 participants