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

[Move] Constrain use of child object of shared object in Move calls #1710

Merged
merged 3 commits into from
May 4, 2022

Conversation

lxfind
Copy link
Contributor

@lxfind lxfind commented May 2, 2022

This PR adds the constrain on how we use child objects of shared objects in Move calls.
Related to #1228
Fixes #1327
We require that one of the types must be defined in the same module.
This does not fully resolve the restricted transfer problem, but it at least makes sure people cannot attack on shared objects by arbitrarily manipulating the child objects.

Added a test, but I would hope for a more comprehensive test. I hope that soon the transaction test framework can support making Move calls so I could write a better test in Move.

@lxfind lxfind force-pushed the move-forbit-child-shared-object branch from 96841d7 to 3356f1b Compare May 2, 2022 15:54
current_module: ModuleId,
) -> SuiResult {
// ancestor_map is a cache that remembers the top ancestor of each object.
// Top ancestor is the object at the top in the object ownership chain whose
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
// Top ancestor is the object at the top in the object ownership chain whose
// Top ancestor is the root at the top in the object ownership chain, which is always an address (not an object)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

hmm that's actually not the intent. I am caching the last object in the object ownership chain (not an address).

@lxfind lxfind force-pushed the move-forbit-child-shared-object branch from 3356f1b to 7391a1a Compare May 4, 2022 17:56
Copy link
Collaborator

@sblackshear sblackshear left a comment

Choose a reason for hiding this comment

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

Thanks for fixing this!

Probably wouldn't hurt to add tests for the cycle case out of paranoia, but this could also be a TODO.

Owner::ObjectOwner(parent_id) => {
cur_id = parent_id.into();
fp_ensure!(
cur_id != ancestor_stack[0],
Copy link
Collaborator

Choose a reason for hiding this comment

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

Nice--IIUC, this also fixes nontrivial cycles (e.g., A owns B owns A....)

@lxfind lxfind enabled auto-merge (squash) May 4, 2022 19:56
@lxfind lxfind merged commit fd98979 into main May 4, 2022
@lxfind lxfind deleted the move-forbit-child-shared-object branch May 4, 2022 20:07
longbowlu pushed a commit that referenced this pull request May 12, 2022
…1710)

* Constrain use of child object of shared object in Move calls

* Address feedback

* Add TODO
punwai pushed a commit that referenced this pull request Jul 27, 2022
…1710)

* Constrain use of child object of shared object in Move calls

* Address feedback

* Add TODO
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.

[MoveLib] Make sure a child object of a shared object cannot be arbitrarily transferred
2 participants