jit: Enable JIT without "std" feature, but with global alloc

[nathanjsweet]

Add a new "alloc" feature that indicates that the crate importing rbpf has an implementation of the GlobalAlloc trait. Memory protection is ignored in the "no_std" environment.

[qmonnet]

Hi Nate, nice to hear from you 🙂 and thanks a lot for this work!

I haven't looked at the details yet, but have you looked at the work from #125? The JIT should be available in no_std now (I see the README.md is outdated in that regard). Is your PR adding something else, or are you trying to achieve the same?

[nathanjsweet]

Yes I saw #125, but passing the library a pointer of bytes creates problems for my use case. Now I have to track those bytes when I don't want to. I would much rather implement GlobalAlloc. Core library crates that have strong use cases for running without "std" use the "alloc" feature coupled with a use of the core::alloc. Both the crossbeam-queue, and the futures-util implement no-std support thus. Definitely some documentation changes are in order regardless of the change. Thanks for taking the time 🙏 !

[Godones]

In this case, the rbpf library cannot ensure that the memory has executable permissions. Developers need to ensure that the memory allocated by GlobalAlloc has executable permissions, which seems unreasonable and dangerous.

[nathanjsweet]

I cleaned up the commit which had some whitespace issues.

@Godones

In this case, the rbpf library cannot ensure that the memory has executable permissions. Developers need to ensure that the memory allocated by GlobalAlloc has executable permissions, which seems unreasonable and dangerous.

Only if they turn on the alloc feature, which is almost always in a kernel or/and embedded environment (which can't offer executable protection). This commit is specifically for this scenario.

[qmonnet]

Sorry for the delay - took me some time to look into this. Thank you also Linfeng for the feedback.

I agree with Nate, it sounds acceptable to leave the user responsible for checking memory permissions, given that the alloc feature is opt-in.

Maybe we could add a comment about this in the feature description in the README, though?

Code looks good otherwise, with just some typos in the README update.

Could you please add a full test or example to show how to use the feature? (It doesn't have to be a complex one, but something providing a basic implementation for GlobalAlloc and running a JITed program on that would help users (and maintainers 😇) understand how to use it.

[qmonnet]

Suggested change

	The `rbpf` crate has a Cargoe featured named "alloc" that is not enabled by
	default. `std` must be turned off and is mutually exclusive with alloc.
	The `rbpf` crate has a Cargo feature named "alloc" that is not enabled by
	default. `std` must be turned off and is mutually exclusive with `alloc`.

[qmonnet]

We also need to adjust the CI runs, where we build with --all-features. Is there a way to make --all-features do all-features-but-actually-not-mutually-exclusive-ones in Rust/Cargo?

[nathanjsweet]

@qmonnet

Sorry for the late reply.

We also need to adjust the CI runs, where we build with --all-features. Is there a way to make --all-features do all-features-but-actually-not-mutually-exclusive-ones in Rust/Cargo?

I've broken this down so that the exclusivity is accounted for in the tests. I've added a warning to the README that informs developers that they will have to update the matrix in order to gain test coverage.

I've also added some basic build coverage for the alloc feature.