Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Refactor runtime table management for more type-safety #8018

Merged
merged 1 commit into from
Feb 28, 2024

Conversation

alexcrichton
Copy link
Member

This commit is an attempt to make the mistake fixed in #8016 harder to happen again. This removes the set_raw helper entirely from tables and instead forces all callers to view the table as either a table of funcrefs or a table of externefs. By forcing that choice outwards instead of handling it inwards it enables dealing with a typed table in more contexts which should help naturally do the right thing.

This commit is an attempt to make the mistake fixed in bytecodealliance#8016 harder to
happen again. This removes the `set_raw` helper entirely from tables and
instead forces all callers to view the table as either a table of
funcrefs or a table of externefs. By forcing that choice outwards
instead of handling it inwards it enables dealing with a typed table in
more contexts which should help naturally do the right thing.
@alexcrichton alexcrichton requested a review from a team as a code owner February 28, 2024 19:19
@alexcrichton alexcrichton requested review from pchickey and fitzgen and removed request for a team and pchickey February 28, 2024 19:19
let table = &mut *instance.get_defined_table(table);
table.init_func(funcref)?;
Copy link
Member Author

Choose a reason for hiding this comment

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

Relative to #8016 this was the other issue I found, this forgot to check whether the table was an externref table or funcref table and triggered a panic by assuming a global was a funcref.

@fitzgen fitzgen added this pull request to the merge queue Feb 28, 2024
Merged via the queue into bytecodealliance:main with commit bc647d4 Feb 28, 2024
19 checks passed
@alexcrichton alexcrichton deleted the more-table-type-safety branch March 11, 2024 18:22
alexcrichton added a commit to alexcrichton/wasmtime that referenced this pull request Apr 2, 2024
This commit fixes an accidental issue introduced in bytecodealliance#8018 where using an
element segment which had been dropped with an `externref` table would
cause a panic. The panic happened due to an assertion that tables are
being used with the right type of item and that was being mismatched.
The underlying issue was that dropped element segments are modeled as an
empty element segment but the empty element segment was using the
"functions" encoding as opposed to the "expressions" encoding. This
meant that code later assumed that due to the use of functions the table
must be a table-of-functions, but this was not correct for
externref-based tables.

The fix in this commit is to instead model the encoding as an
"expressions" list which means that the table type is dispatched on to
call the appropriate initializer.

There is no memory safety issue with this mistake as the assertion was
specifically targetted at preventing memory safety. This does, however,
enable any WebAssembly module to panic a host.

Closes bytecodealliance#8281
alexcrichton added a commit to alexcrichton/wasmtime that referenced this pull request Apr 2, 2024
This commit fixes an accidental issue introduced in bytecodealliance#8018 where using an
element segment which had been dropped with an `externref` table would
cause a panic. The panic happened due to an assertion that tables are
being used with the right type of item and that was being mismatched.
The underlying issue was that dropped element segments are modeled as an
empty element segment but the empty element segment was using the
"functions" encoding as opposed to the "expressions" encoding. This
meant that code later assumed that due to the use of functions the table
must be a table-of-functions, but this was not correct for
externref-based tables.

The fix in this commit is to instead model the encoding as an
"expressions" list which means that the table type is dispatched on to
call the appropriate initializer.

There is no memory safety issue with this mistake as the assertion was
specifically targetted at preventing memory safety. This does, however,
enable any WebAssembly module to panic a host.

Closes bytecodealliance#8281
alexcrichton added a commit to alexcrichton/wasmtime that referenced this pull request Apr 2, 2024
This commit fixes an accidental issue introduced in bytecodealliance#8018 where using an
element segment which had been dropped with an `externref` table would
cause a panic. The panic happened due to an assertion that tables are
being used with the right type of item and that was being mismatched.
The underlying issue was that dropped element segments are modeled as an
empty element segment but the empty element segment was using the
"functions" encoding as opposed to the "expressions" encoding. This
meant that code later assumed that due to the use of functions the table
must be a table-of-functions, but this was not correct for
externref-based tables.

The fix in this commit is to instead model the encoding as an
"expressions" list which means that the table type is dispatched on to
call the appropriate initializer.

There is no memory safety issue with this mistake as the assertion was
specifically targetted at preventing memory safety. This does, however,
enable any WebAssembly module to panic a host.

Closes bytecodealliance#8281
github-merge-queue bot pushed a commit that referenced this pull request Apr 2, 2024
This commit fixes an accidental issue introduced in #8018 where using an
element segment which had been dropped with an `externref` table would
cause a panic. The panic happened due to an assertion that tables are
being used with the right type of item and that was being mismatched.
The underlying issue was that dropped element segments are modeled as an
empty element segment but the empty element segment was using the
"functions" encoding as opposed to the "expressions" encoding. This
meant that code later assumed that due to the use of functions the table
must be a table-of-functions, but this was not correct for
externref-based tables.

The fix in this commit is to instead model the encoding as an
"expressions" list which means that the table type is dispatched on to
call the appropriate initializer.

There is no memory safety issue with this mistake as the assertion was
specifically targetted at preventing memory safety. This does, however,
enable any WebAssembly module to panic a host.

Closes #8281
alexcrichton added a commit that referenced this pull request Apr 2, 2024
This commit fixes an accidental issue introduced in #8018 where using an
element segment which had been dropped with an `externref` table would
cause a panic. The panic happened due to an assertion that tables are
being used with the right type of item and that was being mismatched.
The underlying issue was that dropped element segments are modeled as an
empty element segment but the empty element segment was using the
"functions" encoding as opposed to the "expressions" encoding. This
meant that code later assumed that due to the use of functions the table
must be a table-of-functions, but this was not correct for
externref-based tables.

The fix in this commit is to instead model the encoding as an
"expressions" list which means that the table type is dispatched on to
call the appropriate initializer.

There is no memory safety issue with this mistake as the assertion was
specifically targetted at preventing memory safety. This does, however,
enable any WebAssembly module to panic a host.

Closes #8281
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants