Stream: git-wasmtime

Topic: wasmtime / issue #3897 Compiled Module loading should che...

view this post on Zulip Wasmtime GitHub notifications bot (Mar 08 2022 at 01:27):

pchickey opened issue #3897:

Loading a compiled module into wasmtime may mean the Module was compiled on a different machine. Wasmtime does not provide a mechanism to make sure the set of flags on a compiled module is compatible with the CPU that the compiled module will be executed on.

Presently, when wasmtime loads a compiled Module (e.g. Module::deserialize_file), the isa flags in the loaded module are only checked when cfg(compiler):
https://github.com/bytecodealliance/wasmtime/blob/802302602c94c6c171553d0f2bd2e4a6371ea1fc/crates/wasmtime/src/module/serialization.rs#L316-L321

This check doesn't even perform precisely what we want - it will determine if the Engine's flags are compatible with the loaded module, which do not necessarily match the host cpu.

So, I propose the following additions to wasmtime:

  1. wasmtime::Config should have the target and cranelift_flag_set methods available even when the feature cranelift is not enabled (e.g. in runtime-only mode).
  2. wasmtime::Config should have a setting which mandates that Engine construction validates those target and cranelift flags against the host cpu. This needs to be configable so that an engine Engine can be used for cross-compilation.
  3. When loading a compiled Module, the isa flags should be checked against the Engine settings even when cfg(compiler) is not enabled.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 08 2022 at 01:28):

pchickey assigned issue #3897:

Loading a compiled module into wasmtime may mean the Module was compiled on a different machine. Wasmtime does not provide a mechanism to make sure the set of flags on a compiled module is compatible with the CPU that the compiled module will be executed on.

Presently, when wasmtime loads a compiled Module (e.g. Module::deserialize_file), the isa flags in the loaded module are only checked when cfg(compiler):
https://github.com/bytecodealliance/wasmtime/blob/802302602c94c6c171553d0f2bd2e4a6371ea1fc/crates/wasmtime/src/module/serialization.rs#L316-L321

This check doesn't even perform precisely what we want - it will determine if the Engine's flags are compatible with the loaded module, which do not necessarily match the host cpu.

So, I propose the following additions to wasmtime:

  1. wasmtime::Config should have the target and cranelift_flag_set methods available even when the feature cranelift is not enabled (e.g. in runtime-only mode).
  2. wasmtime::Config should have a setting which mandates that Engine construction validates those target and cranelift flags against the host cpu. This needs to be configable so that an engine Engine can be used for cross-compilation.
  3. When loading a compiled Module, the isa flags should be checked against the Engine settings even when cfg(compiler) is not enabled.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 08 2022 at 01:28):

pchickey unassigned issue #3897 (assigned to cfallin):

Loading a compiled module into wasmtime may mean the Module was compiled on a different machine. Wasmtime does not provide a mechanism to make sure the set of flags on a compiled module is compatible with the CPU that the compiled module will be executed on.

Presently, when wasmtime loads a compiled Module (e.g. Module::deserialize_file), the isa flags in the loaded module are only checked when cfg(compiler):
https://github.com/bytecodealliance/wasmtime/blob/802302602c94c6c171553d0f2bd2e4a6371ea1fc/crates/wasmtime/src/module/serialization.rs#L316-L321

This check doesn't even perform precisely what we want - it will determine if the Engine's flags are compatible with the loaded module, which do not necessarily match the host cpu.

So, I propose the following additions to wasmtime:

  1. wasmtime::Config should have the target and cranelift_flag_set methods available even when the feature cranelift is not enabled (e.g. in runtime-only mode).
  2. wasmtime::Config should have a setting which mandates that Engine construction validates those target and cranelift flags against the host cpu. This needs to be configable so that an engine Engine can be used for cross-compilation.
  3. When loading a compiled Module, the isa flags should be checked against the Engine settings even when cfg(compiler) is not enabled.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 08 2022 at 01:28):

pchickey assigned issue #3897 (assigned to cfallin):

Loading a compiled module into wasmtime may mean the Module was compiled on a different machine. Wasmtime does not provide a mechanism to make sure the set of flags on a compiled module is compatible with the CPU that the compiled module will be executed on.

Presently, when wasmtime loads a compiled Module (e.g. Module::deserialize_file), the isa flags in the loaded module are only checked when cfg(compiler):
https://github.com/bytecodealliance/wasmtime/blob/802302602c94c6c171553d0f2bd2e4a6371ea1fc/crates/wasmtime/src/module/serialization.rs#L316-L321

This check doesn't even perform precisely what we want - it will determine if the Engine's flags are compatible with the loaded module, which do not necessarily match the host cpu.

So, I propose the following additions to wasmtime:

  1. wasmtime::Config should have the target and cranelift_flag_set methods available even when the feature cranelift is not enabled (e.g. in runtime-only mode).
  2. wasmtime::Config should have a setting which mandates that Engine construction validates those target and cranelift flags against the host cpu. This needs to be configable so that an engine Engine can be used for cross-compilation.
  3. When loading a compiled Module, the isa flags should be checked against the Engine settings even when cfg(compiler) is not enabled.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 08 2022 at 01:28):

pchickey assigned issue #3897 (assigned to alexcrichton):

Loading a compiled module into wasmtime may mean the Module was compiled on a different machine. Wasmtime does not provide a mechanism to make sure the set of flags on a compiled module is compatible with the CPU that the compiled module will be executed on.

Presently, when wasmtime loads a compiled Module (e.g. Module::deserialize_file), the isa flags in the loaded module are only checked when cfg(compiler):
https://github.com/bytecodealliance/wasmtime/blob/802302602c94c6c171553d0f2bd2e4a6371ea1fc/crates/wasmtime/src/module/serialization.rs#L316-L321

This check doesn't even perform precisely what we want - it will determine if the Engine's flags are compatible with the loaded module, which do not necessarily match the host cpu.

So, I propose the following additions to wasmtime:

  1. wasmtime::Config should have the target and cranelift_flag_set methods available even when the feature cranelift is not enabled (e.g. in runtime-only mode).
  2. wasmtime::Config should have a setting which mandates that Engine construction validates those target and cranelift flags against the host cpu. This needs to be configable so that an engine Engine can be used for cross-compilation.
  3. When loading a compiled Module, the isa flags should be checked against the Engine settings even when cfg(compiler) is not enabled.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 08 2022 at 15:21):

akirilov-arm commented on issue #3897:

Concerning item 2, there is a subtlety - it might be acceptable to have some discrepancy between the features supported by the host CPU and those used by the compiled module if the difference consists of features that are backward-compatible. Examples are Pointer Authentication and Branch Target Identification from the Arm instruction set architecture (which I am discussing in bytecodealliance/rfcs#17 and have prototyped in PR #3693) and I believe that the ENDBR instruction introduced by Intel CET behaves similarly.

cc @abrown

view this post on Zulip Wasmtime GitHub notifications bot (Mar 08 2022 at 19:58):

alexcrichton commented on issue #3897:

I implemented #3899 in a way that can accomodate the pointer authentication bits since the query made is "is this feature compatible with the native host" so there's room to say whether or not pointer authentication is enabled that's always compatible with the native host (possibly with extra handling to enter/exit the module in a different fashion if it's enabled/disabled).

view this post on Zulip Wasmtime GitHub notifications bot (Mar 09 2022 at 15:46):

alexcrichton closed issue #3897 (assigned to alexcrichton):

Loading a compiled module into wasmtime may mean the Module was compiled on a different machine. Wasmtime does not provide a mechanism to make sure the set of flags on a compiled module is compatible with the CPU that the compiled module will be executed on.

Presently, when wasmtime loads a compiled Module (e.g. Module::deserialize_file), the isa flags in the loaded module are only checked when cfg(compiler):
https://github.com/bytecodealliance/wasmtime/blob/802302602c94c6c171553d0f2bd2e4a6371ea1fc/crates/wasmtime/src/module/serialization.rs#L316-L321

This check doesn't even perform precisely what we want - it will determine if the Engine's flags are compatible with the loaded module, which do not necessarily match the host cpu.

So, I propose the following additions to wasmtime:

  1. wasmtime::Config should have the target and cranelift_flag_set methods available even when the feature cranelift is not enabled (e.g. in runtime-only mode).
  2. wasmtime::Config should have a setting which mandates that Engine construction validates those target and cranelift flags against the host cpu. This needs to be configable so that an engine Engine can be used for cross-compilation.
  3. When loading a compiled Module, the isa flags should be checked against the Engine settings even when cfg(compiler) is not enabled.

Last updated: Dec 23 2024 at 13:07 UTC