A Wasm component running inside of Wasmtime is just fine. However, when you start to use resources from outside of Wasm, e.g. systems, network interfaces, GPUs, etc., Wasmtime uses OS resources from the host that it is running upon. If this host is running on your trusted compute base, then it implies you are trusting the host implementations in Wasmtime, which for some is just fine. However, Hyperlight-Wasm gives platform builders the ability to describe the interface between the guest and the host explicitly, so you could only expose the host functionality you would want with the trusted implementation you'd want. For example, if I'm building a FaaS, I may want to provide only an exported event handler and an imported key/value interface to the guest for which I've built a safe, multi-tenant implementation and strictly disallow all other host provided functionality.
Good question. I think it’s the additional security? From [1]:
> Hyperlight is able to create new VMs in one to two milliseconds. While this is still slower than using sandboxed runtimes like V8 or Wasmtime directly, with Hyperlight we can take those same runtimes and place them inside of a VM that provides additional protection in the event of a sandbox escape.
It's the same reasoning that leads people to move things from running in an OS process to running in a VM. In theory, it adds security and better isolation. Hyperlight appears to substantially reduce the overhead of running VMs which makes it more appealing as a target if this fits your needs and you want the isolation of VMs.