SIMD-0162: Remove Accounts is_executable Flag Checks#162
Conversation
|
|
||
| Error codes of these conditions, which are rarely triggered, will change. | ||
|
|
||
| The only consensus relevant change is that it will become possible (for |
There was a problem hiding this comment.
Will this change open doors for user to withdraw funds from program accounts?
There was a problem hiding this comment.
Also, it seems that this change will open doors for modifying data on executable account, and reset executable flag itself on executable account. Are there any concerns about this for consensus? Should we document the impact of these changes in the SIMD?
There was a problem hiding this comment.
Users will remain unable to: Withdraw funds from program accounts, reset the is_executable flag, or change the data directly without going through the loaders program managements instructions. That is because for that you need to be the owner, but programs are owned by a loader. Thus, the loader decides what happens to program accounts.
buffalojoec
left a comment
buffalojoec
left a comment
There was a problem hiding this comment.
Looks good. I'm just curious how buffer accounts will be handled going forward. I'm assuming that it will simply be the header of the account data UpgradeableLoaderState::Buffer, but maybe mentioning how loaders v3 and v4 distinguish between buffer accounts and programs might be useful, even if unchanged, with this flag removed.
| flag can be addressed in a subsequent proposal. Thus, the following must remain | ||
| unaffected for now: | ||
|
|
||
| - Setting of the `is_executable` flag during program deployment |
There was a problem hiding this comment.
Can we specify that this is for both loaders - v3 and v4?
There was a problem hiding this comment.
Loader-v4 will get its own SIMD explaining it in full detail.
topointon-jump
left a comment
topointon-jump
left a comment
There was a problem hiding this comment.
It's great to simplify things here!
A bit concerned that it's easy to make mistakes here and unintentionally introduce consensus violations, so there will need to be very thorough testing around the failure cases. We have a lot of tooling which can help here.
|
It looks like there's consensus here. If no one objects within the next week, I'll merge this on 25 November. |
buffalojoec
left a comment
buffalojoec
left a comment
There was a problem hiding this comment.
Just a nit as I'm re-reviewing some of these SIMDs. This proposal leans into the second and third constraints for identifying verified on-chain programs:
- Is owned by a loader
- Contains a successfully verified ELF, contains the address of a program data
account which does or is a built-in program
However, it doesn't mention how the third constraint is actually verified. If we're going to make the rule: "only programs owned by any of the four loaders can be considered verified ELFs, and each loader imposes its own standard for querying that verification status", then this proposal should state that more explicitly.
| - CPI ignores changes made by the caller to instruction accounts which have | ||
| the `is_executable` flag set |
There was a problem hiding this comment.
I'm confused why this was left in because by allowing executable accounts to be written, it becomes important that any changes to executable accounts are handled properly.
Without this change, not only does CPI ignore changes made my the caller, it also ignores changes made by the callee. In the latter case, when the caller returns, the runtime will fail the transaction because it will think that the caller tried to revert the callee changes.
Also imagine if during a CPI, both the caller and callee program sent a lamport to an executable account from a non executable writable account. The caller sends the lamport first, then when the callee is cpi'd it hasn't seen the lamport change so when it sends a lamport, the balance is updated to the value that was already updated to by the caller. When the caller returns, the executable account has only received 1 lamport but the sender non executable account has sent two lamports. This leads to a surprising lamport imbalance error.
There was a problem hiding this comment.
Sorry for the ambiguous formulation. What is meant is not that is_executable flag can be set (you can not change the is_executable flag inside the VM anyway), instead it means that CPI behavior was dependent on the state of the is_executable for instruction accounts, and we do not change any of that in this SIMD ("the following must remain unaffected for now").
There was a problem hiding this comment.
We had to leave it in because direct mapping would break otherwise. We can only remove it after activating and cleaning up the feature gate of direct mapping.
There was a problem hiding this comment.
Sorry for the ambiguous formulation. What is meant is not that is_executable flag can be set (you can not change the is_executable flag inside the VM anyway)
I think the SIMD was clear. I wasn't thinking you meant that the is_executable flag can be set. I meant that other fields in executable accounts can be modified now but this CPI behavior would cause surprising errors when executable accounts are modified in otherwise valid ways (e.g. adding lamports as you noted in the impact section)
We had to leave it in because direct mapping would break otherwise. We can only remove it after activating and cleaning up the feature gate of direct mapping.
Surely there was some way to make it work before direct mapping is enabled without breaking direct mapping? Especially if we can remove after direct mapping is activated?
6 participants
No description provided.