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

Detect if the Linux Kernel is in lockdown mode #620

Merged
merged 8 commits into from
Jan 24, 2024

Conversation

grcevski
Copy link
Contributor

@grcevski grcevski commented Jan 22, 2024

This PR adds a Linux Kernel lockdown mode validation check for the two bpf programs which use bpf_probe_write_user. If the kernel is running in lockdown mode (typically auto-enabled with Secure Boot), we now put an explanatory error message instead of 'failed to load bpf program error'.

Relates to #290

@grcevski grcevski requested a review from a team January 22, 2024 19:14
@edeNFed
Copy link
Contributor

edeNFed commented Jan 23, 2024

I am not sure we should completely not load the instrumentation in case the kernel is in lockdown mode.
For example, process-internal context propagation would still work.

What do you think about producing spans and adding an error to them that specify something like context propagation failed please change kernel lockdown mode. I think this can be a good tradeoff between producing the best data that we can during kernel lockdown but also not confusing the users with a log message they will not find.

@grcevski
Copy link
Contributor Author

Sure, I think I can do that. The only way I've been able to do this kind of thing is by using defines, compiling different versions of the BPF programs and loading selectively. I know about the bpf_core_enum_value_exists helper, but I've never been able to use it successfully, the verifier complains regardless of the if statement. Does this make sense, or do you have another approach in mind?

@MrAlias
Copy link
Contributor

MrAlias commented Jan 23, 2024

@edeNFed what do you think about doing that in a follow up PR?

@grcevski
Copy link
Contributor Author

I'm happy to work on extending this PR and following with another that does the partial trace support. It will be easier for review if we are doing it incrementally, but I don't mind to extend this one if that's preferred.

@edeNFed
Copy link
Contributor

edeNFed commented Jan 24, 2024

@grcevski @MrAlias I am good with both options. Whatever easier for you.

@MrAlias MrAlias added this to the v0.11.0-alpha milestone Jan 24, 2024
@MrAlias MrAlias merged commit f9aa47a into open-telemetry:main Jan 24, 2024
16 checks passed
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