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.

Sign up for GitHub

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

Jump to bottom

[fastx adapter] bytecode verifier pass to ensure immutability + non-reuse of ID's #18

Closed
sblackshear opened this issue Dec 2, 2021 · 1 comment
Closed

[fastx adapter] bytecode verifier pass to ensure immutability + non-reuse of ID's #18

sblackshear opened this issue Dec 2, 2021 · 1 comment
Assignees
@lxfind

Comments

@sblackshear
Copy link
Collaborator

  • Every object in the fastX global pool must have an ID (see [fastx adapter] bytecode verifier pass to ensure all global objects have ID's #15)
  • These ID's need to be immutable. This can be enforced with a simple per-instruction check (e.g., flag BorrowField instructions that try to look at an id field of an object with the key ability)
  • In addition, if an object is destroyed via the Unpack instruction, it's ID will end up on the stack. This ID should not flow into another object, as that will cause confusion in the world of clients (e.g., an object ID may appear to become associated with new data of a completely different type). This can be enforced with an escape analysis: taint an unpacked ID and ensure that it does not flow into a return value, a Pack or a WriteRef.
  • This code implements an escape analysis inside the Move prover and might be useful to look at/steal abstract domains from.

Note: the escape analysis will be the most complicated fastX bytecode verifier pass by a good margin. The code for this bytecode verifier pass should live in the fastNFT repo + be run in the adapter on the code path for publishing new Move modules.
This was referenced Dec 2, 2021
Open
Closed
@lxfind lxfind self-assigned this Dec 15, 2021
@lxfind
Copy link
Contributor

lxfind commented Dec 29, 2021

Immutability is verified in #95.
No reuse of ID is verified in #77.

@lxfind lxfind closed this as completed Dec 29, 2021
mwtian pushed a commit that referenced this issue Sep 12, 2022
Merge pull request #18 from asonnino/narwhal-hs
539a6bb 
HotStuff on Steroids
mwtian pushed a commit to mwtian/sui that referenced this issue Sep 29, 2022
Merge pull request MystenLabs#18 from asonnino/narwhal-hs
db116f4 
HotStuff on Steroids
brson pushed a commit to brson/sui that referenced this issue Apr 30, 2024
@ksolana
Gas limit to limit execution of unbounded methods (MystenLabs#18)
5d9eaf6 
After Jan's fix on adding terminators to basic blocks with
infinite loops, all the remaining tests can be fixed by having
a reasonable compute budget. This patch creates a new compute
budget for Solana tests.
    
A possible extension will be to allow each test to specify
a compute budget (added as a TODO in
test_runner.rs:exec_module_tests_solana)
brson pushed a commit to brson/sui that referenced this issue Apr 30, 2024
@ksolana
Test cfg for gas_budget::compute_unit_limit
9ff25c7 
Tests can now add compute_unit_limit as a config.

Followups:

    Remove DEFAULT_EXECUTION_BOUND_SOLANA_STDLIB_TEST added in MystenLabs#18
    Parse GAS_BUDGET_HEAP_SIZE
    Parse GAS_BUDGET_MAX_CALL_DEPTH

Fixes: MystenLabs#20
brson pushed a commit to brson/sui that referenced this issue Apr 30, 2024
@ksolana
Test cfg for gas_budget::compute_unit_limit (MystenLabs#21)
1e367b5 
Tests can now add compute_unit_limit as a config.

Followups
- Remove `DEFAULT_EXECUTION_BOUND_SOLANA_STDLIB_TEST` added in MystenLabs#18
- Parse GAS_BUDGET_HEAP_SIZE
- Parse GAS_BUDGET_MAX_CALL_DEPTH

Fixes: MystenLabs#20
wlmyng added a commit that referenced this issue Jun 25, 2024
@wlmyng
[gql][pick-2024.4.0]explicitly setup test scenario for test_query_def…
0da3aef 
…ault_page_limit (#18… (#18394)

…393)

Unblock #18277 by explicitly
setting up the correct test scenario for the
`test_query_default_page_limit` test.

I think we can follow this up with
1. instead of using the same db url, follow sui-graphql-e2e-tests
pattern and generate unique db urls for each test
2. this is so that we can run tests in parallel instead of sequentially
(which is the case today due to the serial)
3. we can leverage ExecutorCluster.cleanup_resources to cleanup each
test

How did you test the new or updated feature?

---

Check each box that your changes affect. If none of the boxes relate to
your changes, release notes aren't required.

For each box you select, include information after the relevant heading
that describes the impact of your changes that a user might notice and
any actions they must take to implement updates.

- [ ] Protocol:
- [ ] Nodes (Validators and Full nodes):
- [ ] Indexer:
- [ ] JSON-RPC:
- [ ] GraphQL:
- [ ] CLI:
- [ ] Rust SDK:

## Description 

Describe the changes or additions included in this PR.

## Test plan 

How did you test the new or updated feature?

---

## Release notes

Check each box that your changes affect. If none of the boxes relate to
your changes, release notes aren't required.

For each box you select, include information after the relevant heading
that describes the impact of your changes that a user might notice and
any actions they must take to implement updates.

- [ ] Protocol: 
- [ ] Nodes (Validators and Full nodes): 
- [ ] Indexer: 
- [ ] JSON-RPC: 
- [ ] GraphQL: 
- [ ] CLI: 
- [ ] Rust SDK:
wlmyng added a commit that referenced this issue Jun 25, 2024
@wlmyng
[pick][gql-2024.1.0] explicitly setup test scenario for test_query_de…
246f4e4 
…fault_page_limit (#18… (#18395)

…393)

Unblock #18277 by explicitly
setting up the correct test scenario for the
`test_query_default_page_limit` test.

I think we can follow this up with
1. instead of using the same db url, follow sui-graphql-e2e-tests
pattern and generate unique db urls for each test
2. this is so that we can run tests in parallel instead of sequentially
(which is the case today due to the serial)
3. we can leverage ExecutorCluster.cleanup_resources to cleanup each
test

How did you test the new or updated feature?

---

Check each box that your changes affect. If none of the boxes relate to
your changes, release notes aren't required.

For each box you select, include information after the relevant heading
that describes the impact of your changes that a user might notice and
any actions they must take to implement updates.

- [ ] Protocol:
- [ ] Nodes (Validators and Full nodes):
- [ ] Indexer:
- [ ] JSON-RPC:
- [ ] GraphQL:
- [ ] CLI:
- [ ] Rust SDK:

## Description 

Describe the changes or additions included in this PR.

## Test plan 

How did you test the new or updated feature?

---

## Release notes

Check each box that your changes affect. If none of the boxes relate to
your changes, release notes aren't required.

For each box you select, include information after the relevant heading
that describes the impact of your changes that a user might notice and
any actions they must take to implement updates.

- [ ] Protocol: 
- [ ] Nodes (Validators and Full nodes): 
- [ ] Indexer: 
- [ ] JSON-RPC: 
- [ ] GraphQL: 
- [ ] CLI: 
- [ ] Rust SDK:
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@lxfind lxfind

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@lxfind @sblackshear