Support for hypervisor extensions in the Cartesi Machine

Technical Vision Forum Technical Evolution Plan
1

The Machine Reference Unit has been working on adding Hypervisor support for the Cartesi Machine.
A hypervisor is a hardware-assisted mechanism that can be used to safely run separate programs, or even operating systems, concurrently, on the same computer.

The motivation for the addition of hypervisor support to Cartesi Machines was the desire for a chain of “privileged components” that could run before, or after the components under the control of untrusted developers, in such a way that these untrusted components could not interfere with the operation of the privileged ones. This would reduce the amount of trust a third-party must have on untrusted DApp developers in certain interactions. For example, if there is a known and audited privileged wallet component in charge of all monetary transfers into and out of a DApp, liquidity providers would feel more comfortable fronting money even before finalization, safe in the knowledge that they would be reimbursed by the trusted wallet component despite the presence of untrusted components.

Since then, other potential applications for hypervisor support appeared. For example, it could be used to protect the DApp from code submitted by untrusted users that it wants to run. Think a game, in which the users submit their strategies in the form of programs. Or perhaps a bug-bounty program in which an exploit for a certain piece of code is submitted by users and tested in isolation, so it cannot affect other parts of the DApp.

The RISC-V hypervisor extensions were proposed in 2017 and ratified in 2021. Although there are already emulators supporting the extension, it is only expected to appear in hardware implementations in 2024. The extension is complex enough that it could only be added to the Cartesi Machine after the addition of the microarchitecture in late 2022. (The microarchitecture allows us to add extensions to the Cartesi Machine without having to implement these extensions in the matching Solidity implementation.)

We have an operational prototype implementation currently under review before merge into the main branch. This review process is evaluating the implementation for deviations from the standard, for its “simplicity”, for performance when hypervisor extensions are in use, and for its potential impact on the performance of applications that do not use the extensions.

6 Likes
2

Hi @Diego, just moved this to the Technical Vision Forum.

2 Likes
3

Hi there, Diego, I am also in support of this, for reasons that are alternate.

I am currently considering using the Cartesi Machine and system for a project I’m developing called “Slumberer Sentinels.” This project involves using a Hyperconverged Hypervisor (IE: A cloud-only hypervisor) to save, load, and maintain a virtual machine state of a child machine running UNDERTALE.

While UNDERTALE is currently working in Ubuntu, I think it requires x86 libraries. A colleague who is consulting and advising me on means by which I could run UNDERTALE on a RISC/V chipset suggested I run QEMU on a hypervisor to run the x86 machine on the child. This would only be possible with Cartesi if, for example, the Cartesi Machine had Hypervisor support.

Because I missed another conversation with OpenStack regarding their lack of virtual machine state pausing, saving, and loading, I don’t want to miss out on this conversation within Cartesi. There are other use cases besides and including what Diego proposes here, and I hope this prototype becomes merged into the main branch after review. Thank you all for your consideration and work on Cartesi, I wish you success no matter the result of this conversation. Assalamu Alaikum.

Filene Taylor (tsey/tsem/tseir(s))

4

The hypervisor implementation was completed in a separate branch of the Cartesi Machine implementation (GitHub - cartesi/machine-emulator at hypervisor). It works well, but adds a lot of complexity to the emulator. While the implementation was on-going, an alternative to hypervisors was proposed in the form of “machine stacks”. These are, in essence, Cartesi Machines that can operate on other Cartesi Machines. This solution was considered superior, for a variety of reasons, and therefore the hypervisor effort was put on hold until we are certain that “machine stacks” will not be implemented.