Skip to content

Conversation

LXIF
Copy link
Contributor

@LXIF LXIF commented Jun 10, 2025

Motivation

To address ProdSec finding F01, we are changing the OriginHash to be the full 32-bytes. This is a draft because we'd still need to address memory migration.

Changes

Change the StorableOriginHash to 32 bytes, update its functions accordingly.

Tests

No new tests were added.

@LXIF LXIF marked this pull request as draft June 10, 2025 11:41
@LXIF LXIF marked this pull request as ready for review June 10, 2025 13:46
@LXIF LXIF requested review from lmuntaner and sea-snake June 10, 2025 13:46
Comment on lines 756 to 757
// Check that the memory is empty, otherwise panic
assert_eq!(self.lookup_application_with_origin_memory.len(), 0);
Copy link
Contributor

Choose a reason for hiding this comment

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

Given that running below insert is a noop, I don't think we need this guard.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I interpret this as meaning that it does not destroy anything - true, I had this in so we definitely don't forget to remove it afterwards, but I can also take out the check.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Removed ✅

@LXIF LXIF requested a review from sea-snake June 10, 2025 14:15
Copy link
Collaborator

@lmuntaner lmuntaner left a comment

Choose a reason for hiding this comment

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

Could we have a short document of how we expect to do this migration.

This is touching the storage layer and it's important because it uses post_upgrade, which if we mess up we are very much screwed.

Therefore, I think that a short design doc explaining what we want to do is time well spent.

const LOOKUP_APPLICATION_WITH_ORIGIN_MEMORY_INDEX: u8 = 12u8;
// This memory index has been abandoned, do not use it
// const LOOKUP_APPLICATION_WITH_ORIGIN_MEMORY_INDEX: u8 = 12u8;
const LOOKUP_APPLICATION_WITH_ORIGIN_MEMORY_INDEX: u8 = 19u8;
Copy link
Collaborator

Choose a reason for hiding this comment

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

Should we have this after the STABLE_ACCOUNT_COUNTER_DISCREPANCY_COUNTER_MEMORY_INDEX which is the 18 index?

Otherwise I can see ourselves adding the 19 again...

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sure, why not.


/// Used for migrating from 8-byte to 32-byte origin hash
pub fn rebuild_lookup_application_with_origin_memory(&mut self) {
self.stable_application_memory
Copy link
Collaborator

Choose a reason for hiding this comment

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

Won't this be pointing to the new stable memory with index 19?

We need to keep both accessible until we finish the migration, right?

Copy link
Contributor Author

@LXIF LXIF Jun 16, 2025

Choose a reason for hiding this comment

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

self.stable_application_memory points to memory ID 11. We only need to rebuild the lookup table, as it is the only place the origin hash is used. The old lookup table can be discarded.

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.

4 participants