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

Fix - loader-v4 #3586

Merged
merged 4 commits into from
Nov 14, 2024
Merged

Fix - loader-v4 #3586

merged 4 commits into from
Nov 14, 2024

Conversation

Lichtso
Copy link

@Lichtso Lichtso commented Nov 12, 2024

Problem

While writing the integration tests for loader-v4 I noticed several issues.
The rekeying of the associated feature gate will happen separately in #2796.

Summary of Changes

  • Fix program runtime environment of loader-v4. It was still using the v2 environment in load_program_with_pubkey().

  • Removes program account check in loader-v4 execution. Because there should be no need to look at the program account at all during execution as we have the cached program entry.

  • Loader-v4 needs to use the same verification logic during deployment as in loader-v3. This prevents programs with certain syscalls from being deployed.

@Lichtso Lichtso added the v2.1 Backport to v2.1 branch label Nov 12, 2024
Copy link

mergify bot commented Nov 12, 2024

The Firedancer team maintains a line-for-line reimplementation of the
native programs, and until native programs are moved to BPF, those
implementations must exactly match their Agave counterparts.
If this PR represents a change to a native program implementation (not
tests), please include a reviewer from the Firedancer team. And please
keep refactors to a minimum.

Copy link

mergify bot commented Nov 12, 2024

Backports to the beta branch are to be avoided unless absolutely necessary for fixing bugs, security issues, and perf regressions. Changes intended for backport should be structured such that a minimum effective diff can be committed separately from any refactoring, plumbing, cleanup, etc that are not strictly necessary to achieve the goal. Any of the latter should go only into master and ride the normal stabilization schedule. Exceptions include CI/metrics changes, CLI improvements and documentation updates on a case by case basis.

@@ -103,94 +103,96 @@ pub fn load_program_from_bytes(
Ok(loaded_program)
}

Copy link
Author

Choose a reason for hiding this comment

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

This used to be a function direct_deploy_program() invoking an inner macro deploy_program!().
And now is a macro deploy_program!() invoking an inner function deploy_program_internal().
Swapping the roles of the macro and wrapper function allows us to get rid of some lifetime shenanigans and explicit drop(). It is a pure syntactic refactoring and should have no effect on the behavior.

allows us to get rid of some lifetime shenanigans and explicit drop().
It is a pure syntactic refactoring and should have no effect on the behavior.
@Lichtso Lichtso merged commit 8bf688f into anza-xyz:master Nov 14, 2024
50 checks passed
@Lichtso Lichtso deleted the fix/loader_v4 branch November 14, 2024 19:26
mergify bot pushed a commit that referenced this pull request Nov 14, 2024
* Swapping the roles of the macro and wrapper function
allows us to get rid of some lifetime shenanigans and explicit drop().
It is a pure syntactic refactoring and should have no effect on the behavior.

* Loader-v4 needs to use the same verification logic during deployment as is in loader-v3.

* Removes program account check in loader-v4 execution.

* Fix program runtime environment of loader-v4.

(cherry picked from commit 8bf688f)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
v2.1 Backport to v2.1 branch
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants