-
Notifications
You must be signed in to change notification settings - Fork 3
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
Program: add custom error codes for readonly writes #43
Conversation
f6465f3
to
713983f
Compare
This comment was marked as resolved.
This comment was marked as resolved.
713983f
to
24dce76
Compare
24dce76
to
4b0dbbf
Compare
4b0dbbf
to
85efb5b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good! Just the one bit about the error code, but that can get changed later if needed
program/src/error.rs
Outdated
pub enum AddressLookupTableError { | ||
/// Instruction modified data of a read-only account. | ||
#[error("Instruction modified data of a read-only account")] | ||
ReadonlyDataModified = 10, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a reason this is 10
? The other PR didn't set a number
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oops, accidentally removed my comment, but it's to avoid collisions with the custom errors from System program.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added the comment back!
Problem
Working more with the Firedancer conformance harness, yet another inconsequential mismatch between the BPF version and its original builtin version has popped up.
When a builtin program attempts to write to an executable or read-only account, it will be immediately rejected by the
TransactionContext
. However, BPF programs do not query theTransactionContext
for the ability to perform a write. Instead, they perform writes at-will, and the loader will inspect the serialized account memory region for any account update violations after the VM has completed execution.The loader's inspection will catch any unauthorized modifications, however, when the exact same data is written to the account, thus rendering the serialized account state unchanged, the program succeeds.
Summary of Changes
In order to maximize backwards compatibility between the BPF version and its original builtin, we add these checks from
TransactionContext
to the program directly, to throw even when the data being written is the same as what's currently in the account.Unfortunately, the two
InstructionError
variants thrown do not haveProgramError
counterparts, so we mock them out with custom error codes.