Skip to content

Conversation

@buffalojoec
Copy link
Contributor

Problem

Working with the Firedancer conformance suite revealed a relatively inconsequential control flow mismatch between the BPF version of the Config program and its original builtin version.

The limited_deserialize function is designed to stop deserialization at some input buffer length cap, but it does not limit memory allocations as a result of some deserialized vector length. In the case of ConfigKeys, a very large ShortU16 length value could be provided to the program's input, forcing the deserialization step to allocate space for a massive vector of (Pubkey, bool), exhausting the BPF program's heap.

The program would still fail, but the error would be different between the builtin and BPF versions. To ensure maximum backwards compatibility, and to give developers a more proper error code, the BPF program's deserialization needs an additional check for allocation size.

Summary of Changes

Add a check for the provided ShortU16 vector length to the program's input deserialization, to catch any would-be large vector allocations before causing an OOM.

@buffalojoec buffalojoec requested a review from joncinque October 31, 2024 17:05
Copy link
Contributor

@joncinque joncinque left a comment

Choose a reason for hiding this comment

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

The change looks good! Just a few little things

Copy link
Contributor

Choose a reason for hiding this comment

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

Is the extra check that expensive? Why are all the CU numbers so much higher? Or is it a new toolchain?

Copy link
Contributor Author

@buffalojoec buffalojoec Oct 31, 2024

Choose a reason for hiding this comment

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

I'm not sure why CUs changed so much, or why the change isn't constant, but I've built this branch with CLI v2.0.2 as declared in the workspace manifest. I cannot guarantee I've always built with v2.0.2 though...

Copy link
Contributor

@joncinque joncinque left a comment

Choose a reason for hiding this comment

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

Looks great!

@buffalojoec buffalojoec merged commit 0088838 into main Nov 1, 2024
9 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