Move contents of wasm.Module to an internal package and replace it with an interface #232
Comments
codefromthecrypt
pushed a commit
that referenced
this issue
Feb 14, 2022
Per #232, we will be unexporting fields only used during instantiate. Any additional custom sections are unusable otherwise, so this skips them. In doing so, this eliminates a length check bug, some TODO and some logic that enforced strict name uniqueness even though that only rule only applied to the name section. Note: this doesn't restrict future use of custom sections, ex for DWARF, just we don't buffer sections we don't use anymore. See https://www.w3.org/TR/wasm-core-1/#custom-section%E2%91%A0 Signed-off-by: Adrian Cole <adrian@tetrate.io>
codefromthecrypt
added a commit
that referenced
this issue
Feb 14, 2022
Per #232, we will be unexporting fields only used during instantiate. Any additional custom sections are unusable otherwise, so this skips them. In doing so, this eliminates a length check bug, some TODO and some logic that enforced strict name uniqueness even though that only rule only applied to the name section. Note: this doesn't restrict future use of custom sections, ex for DWARF, just we don't buffer sections we don't use anymore. See https://www.w3.org/TR/wasm-core-1/#custom-section%E2%91%A0 Signed-off-by: Adrian Cole <adrian@tetrate.io>
r8d8
pushed a commit
to r8d8/wazero
that referenced
this issue
Feb 14, 2022
Per tetratelabs#232, we will be unexporting fields only used during instantiate. Any additional custom sections are unusable otherwise, so this skips them. In doing so, this eliminates a length check bug, some TODO and some logic that enforced strict name uniqueness even though that only rule only applied to the name section. Note: this doesn't restrict future use of custom sections, ex for DWARF, just we don't buffer sections we don't use anymore. See https://www.w3.org/TR/wasm-core-1/#custom-section%E2%91%A0 Signed-off-by: Adrian Cole <adrian@tetrate.io> Signed-off-by: r8d8 <ckryvomaz@gmail.com>
|
this is done via |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently, we are doing some re-validation because
wasm.Moduleis not required to be created by aModuleDecoder. For example, we double-check certain things like the start function pointing to a valid function type. These sorts of checks can and should be done when parsing/decoding as otherwise you don't know where the failure line/col was. Moreover, there are so many rules that it is a fools errand to repeat each one in instantiate: we'd end up with a lot of code that isn't necessary if decoded properly. Finally, exposing fields like theCodeSectionto mutation allow some pretty severe bugs to be possible. For example, someone could by accident mess up a signature order, something that decoders already enforce.I don't think 3rd party manual instantiation of
wasm.Moduleis viable. The only sustainable way is via validating decoders which we already maintain. I believe that we should instead move the existing logic ofwasm.Moduleinternal, guaranteeing it is only created by our trusted decoders. We'd backfillwasm.Moduleas a struct or interface that has no exported mutable fields, but could be implemented by or contain an internalwasm.Modulecreated by the decoder.Doing this allows us to move all validation possible to do during decoding to the edge and guarantee we can count on that having happened prior to instantiate. This also removes a large bug source area of random or misunderstood contents in function code or constant declarations.
The text was updated successfully, but these errors were encountered: