Skip to content

Remove the Paged memory initialization variant#4046

Merged
alexcrichton merged 2 commits into
bytecodealliance:mainfrom
alexcrichton:remove-paged-memory
May 5, 2022
Merged

Remove the Paged memory initialization variant#4046
alexcrichton merged 2 commits into
bytecodealliance:mainfrom
alexcrichton:remove-paged-memory

Conversation

@alexcrichton
Copy link
Copy Markdown
Member

This commit simplifies the MemoryInitialization enum by removing the
Paged variant. The Paged variant was originally added for uffd, but
that support has now been removed in #4040. This is no longer necessary
but is still used as an intermediate step of becoming a Static variant
of initialized memory (which copy-on-write uses). As a result this
commit largely modifies the static initialization of memory steps and
folds the two methods together.

This commit simplifies the `MemoryInitialization` enum by removing the
`Paged` variant. The `Paged` variant was originally added for uffd, but
that support has now been removed in bytecodealliance#4040. This is no longer necessary
but is still used as an intermediate step of becoming a `Static` variant
of initialized memory (which copy-on-write uses). As a result this
commit largely modifies the static initialization of memory steps and
folds the two methods together.
@alexcrichton alexcrichton requested a review from peterhuene April 19, 2022 14:31
Copy link
Copy Markdown
Member

@peterhuene peterhuene left a comment

Choose a reason for hiding this comment

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

👍 just some comment typos.

Sorry for the delayed review, I missed this review request.

Comment thread crates/environ/src/module.rs Outdated
Comment thread crates/environ/src/module.rs Outdated
Co-authored-by: Peter Huene <peter@huene.dev>
@alexcrichton alexcrichton merged commit 7fdc616 into bytecodealliance:main May 5, 2022
@alexcrichton alexcrichton deleted the remove-paged-memory branch May 5, 2022 14:44
alexcrichton added a commit to alexcrichton/wasmtime that referenced this pull request May 9, 2022
This commit fixes an issue introduced in bytecodealliance#4046 where the checks for
ensuring that the memory initialization image for a module was
constrained in its size failed to trigger and a very small module could
produce an arbitrarily large memory image.

The bug in question was that if a module only had empty data segments at
arbitrarily small and large addresses then the loop which checks whether
or not the image is allowed was skipped entirely since it was seen that
the memory had no data size. The fix here is to skip segments that are
empty to ensure that if the validation loop is skipped then no data
segments will be processed to create the image (and the module won't end
up having an image in the end).
alexcrichton added a commit that referenced this pull request May 9, 2022
This commit fixes an issue introduced in #4046 where the checks for
ensuring that the memory initialization image for a module was
constrained in its size failed to trigger and a very small module could
produce an arbitrarily large memory image.

The bug in question was that if a module only had empty data segments at
arbitrarily small and large addresses then the loop which checks whether
or not the image is allowed was skipped entirely since it was seen that
the memory had no data size. The fix here is to skip segments that are
empty to ensure that if the validation loop is skipped then no data
segments will be processed to create the image (and the module won't end
up having an image in the end).
alexcrichton added a commit to alexcrichton/wasmtime that referenced this pull request May 9, 2022
…e#4112)

This commit fixes an issue introduced in bytecodealliance#4046 where the checks for
ensuring that the memory initialization image for a module was
constrained in its size failed to trigger and a very small module could
produce an arbitrarily large memory image.

The bug in question was that if a module only had empty data segments at
arbitrarily small and large addresses then the loop which checks whether
or not the image is allowed was skipped entirely since it was seen that
the memory had no data size. The fix here is to skip segments that are
empty to ensure that if the validation loop is skipped then no data
segments will be processed to create the image (and the module won't end
up having an image in the end).
alexcrichton added a commit that referenced this pull request May 9, 2022
This commit fixes an issue introduced in #4046 where the checks for
ensuring that the memory initialization image for a module was
constrained in its size failed to trigger and a very small module could
produce an arbitrarily large memory image.

The bug in question was that if a module only had empty data segments at
arbitrarily small and large addresses then the loop which checks whether
or not the image is allowed was skipped entirely since it was seen that
the memory had no data size. The fix here is to skip segments that are
empty to ensure that if the validation loop is skipped then no data
segments will be processed to create the image (and the module won't end
up having an image in the end).
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.

2 participants