uhyve - A minimal hypervisor for RustyHermit

uhyve is small hypervisor to boot the library operating systems Rust website and follow the installation instructions

uhyve - A minimal hypervisor for RustyHermit

Introduction

uhyve is small hypervisor to boot the library operating systems RustyHermit, which is a unikernel operating system targeting a scalable and predictable runtime behavior for HPC and cloud environments.

Warning: At the moment uhyve grants full host file system access from within the unikernel with the permissions of the user running uhyve. Thus, it should not be used for applications which require isolation from the host system.

Installation

An installation of the Rust toolchain is required. Please visit the Rust website and follow the installation instructions. The project can then be installed with the following command:

Requirements

Linux

To check if your system supports virtualization, you can use the following command:

On Linux, uhyve depends on the virtualization solution KVM (Kernel-based Virtual Machine). If the following command gives you some output, you are ready to go!

NOTE: If in case the above steps don't work, make sure to check in your BIOS settings that virtualization is enabled there.

macOS

Disclaimer: Currently, uhyve is mainly developed for Linux. The macOS version has not been tested extensively and does not support all features of the Linux version.

Apple's Command Line Tools must be installed. The following terminal command installs these tools without Apple's IDE Xcode:

Additionally, the included hypervisor bases on the Hypervisor Framework depending on OS X Yosemite (10.10) or newer. To verify if your processor is able to support this framework, run the following in your Terminal:

The output kern.hv_support: 1 indicates virtualization support.

Starting with Big Sur, all processes using the Hypervisor API must have the com.apple.security.hypervisor entitlement and therefore must be signed.

Building from source

To build from source, simply checkout the code and use cargo build.

Signing uhyve to run on macOS Big Sur

uhyve can be self-signed with the following command.

The file app.entitlements must have following content:

For further details have a look at Apple's documentation.

Running RustyHermit apps within uhyve

Use the hypervisor to start the unikernel.

Configuration

uhyve can be configured via environment variables. The following variables are supported.

  • HERMIT_CPUS: specifies the number of cores the virtual machine may use.
  • HERMIT_MEM: defines the memory size of the virtual machine. The suffixes M and G can be used to specify a value in megabytes or gigabytes, respectively.
  • setting HERMIT_VERBOSE to 1 makes the hypervisor print kernel log messages to the terminal.
  • HERMIT_GDB_PORT=port activate a gdb server for the application running inside uhyve. See below

By default, the loader initializes a system with one core and 512 MiB RAM.

Example: the following command starts the demo application in a virtual machine, which has 4 cores and 8GiB memory:

Debugging of RustyHermit apps (unstable)

Basic support of (single-core) applications is already integrated into uhyve. By specifying variable HERMIT_GDB_PORT=port, uhyve is working as gdbserver and is waiting on port port for a connection to a gdb. For instance, with the following command uhyve is waiting on port 6677 for a connection.

In principle, every gdb-capable IDE should be able to debug RustyHermit applications. (Eclipse, VSCode, ...)

The repository rusty-hermit provides example configuration files to debug a RustyHermit application with Visual Code.

Known issues

  • Uhyve isn't able to pass more than 128 environment variables to the unikernel.

Licensing

Licensed under either of

  • Apache License, Version 2.0, (LICENSE-APACHE or http://www.apache.org/licenses/LICENSE-2.0)
  • MIT license (LICENSE-MIT or #404)

at your option.

Contribution

Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.

Issues

Collection of the latest Issues

stlankes

stlankes

1

@simonschoening wrote a prototype for RISC-V. We should integrate this prototype to our version of uhyve.

stlankes

stlankes

0

uhyve should load the application at random start addresses. This is an important step to support ASLR.

mkroening

mkroening

0

Not having to build uhyve in our other project's CI should speed them up.

mkroening

mkroening

1

We might want to migrate to vm-virtio for virtio abstractions. Version 0.1.0 should release soon.

Harry-R

Harry-R

1

uhyve grants full host file system access from within the unikernel with the permissions of the user running uhyve. Thus, a malicious or compromised unikernel (application) could compromise the host system. As one of the advertised security aspects of unikernels is their strong isolation against the host system and other unikernels, this is nothing one would expect from a hypervisor designed for a unikernel. One possible solution would be to allow access only to a certain shared folder of which the path can be passed to uhyve on startup. However, until this is fixed (or if the full host file system access is considered a feature and not a bug) it should be properly documented in the README file.

Harry-R

Harry-R

0

Currently RustyHermit and uhyve lack of stdin support. It would be great to have this feature for testing purposes.

jounathaen

jounathaen

0

I think we don't have a test for multicore uhyve and that's something we should fix ;-)

lonnietc

lonnietc

enhancement
16

Hello,

Right now, it seems that uhyve is used to test unikernel builds, but I need a single instance virtualization application that is compiled with a unikernel.

I am working on a project and would like to compile bhyve or xhyve which are C/C++, or possibly uhyve (Rust) to be build with the unikernel as well.

Can this be accomplished?

jbreitbart

jbreitbart

1

This is not a bug report, just a collection of measurements I did so they won't get lost. Overall, executing the hello_world binary takes about 131ms with uhyve compiled for release.

Running uhyve with valgrind --tool=callgrind --dump-instr=yes --collect-jumps=yes --simulate-cache=yes shows the following runtime distribuation

  • 13% is spent in the runtime linker _dl_start
  • 3% is consumed in std::rt::lang_start_internal

When only considering uhyve::main the runtime is spent almost completly (~98%) in vm::Vm::load_kernel. About 7% is used to measure the TSC and 89% is spent in memcpy, some of which are unnecessary as the content from the elf file is copied twice:

  • uhyve prepares the elf file so it can be executed in the VM
  • the elf crate copies the content of the elf file to its internal data arrays

The later part is unnecessary, as neither uhyve not the functions we use from the elf crate use these data arrays. Removing https://github.com/cole14/rust-elf/blob/master/src/lib.rs#L212-L239 save ~3-4ms with the hello_world example, probably more when running a larger binary.

uhyve_callgraph

jounathaen

jounathaen

0

Uhyve provides SHUTDOWN_PORT as well as UHYVE_PORT_EXIT. libhermit-rs only uses UHYVE_PORT_EXIT so the SHUTDOWN_PORT is probably obsolete...

jschwe

jschwe

7

Uhyve should exit with a non-zero exitcode if the kernel panics. This is important for testing rusty-hermit with uhyve and CI, since I'm not a fan of parsing the output of stdout or stderr to determine if a program failed.

I'm not sure if Uhyve always returns a zero, but at least in the cases I've seen where uhyve shuts down due to a panic of the kernel, the exit code was zero.

jschwe

jschwe

10

When using nested virtualization rusty-hermit currently panics when detecting the cpu frequency, since all methods fail. Uhyve should provide the CPU frequency even in a nested virtualization environment. This can be done either by ensuring detect_from_hypervisor() works or by modifying the CPUid brandstring to contain the clockspeed.

Also (this still needs some more testing on my side though) uhyve should print error messages / quit in the same way for nested virtualization as it does for normal virtualization. Currently uhyve seems to print less when using nested virtualization.

Versions

Find the latest versions by id

v0.0.28 - May 10, 2021

  • Bump kvm-bindings from 0.3.0 to 0.4.0 #101
  • fix bug in the evaluation of cpuid entries
  • Bump goblin from 0.3.4 to 0.4.0 #100
  • Bump byteorder from 1.4.2 to 1.4.3 #93

v0.0.26 - Jan 19, 2021

  • fix emulation of the IO-APIC for macOS Big Sur #60
  • added instrument feature using rftrace #64

v0.0.25 - Jan 17, 2021

  • prevent VM exits due to HLT/MWAIT instructions (#59)
  • Improve Hugepage detection and parameters (#44)
  • Add option to bind vCPUs to host CPUs (#51)

v0.0.24 - Dec 09, 2020

v0.0.23 - Nov 02, 2020

Information - Updated Jun 23, 2022

Stars: 125
Forks: 20
Issues: 29

Repositories & Extras

CDRS is looking for maintainers

CDRS is Apache Cassandra driver written in pure Rust

CDRS is looking for maintainers
Http

371

A push parser for the HTTP 1

Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2

A push parser for the HTTP 1

The arkworks ecosystem consist of Rust libraries for designing and working with zero knowledge succinct...

This library is released under the MIT License and the Apache v2 License (see License)

The arkworks ecosystem consist of Rust libraries for designing and working with zero knowledge succinct...

Say Hello To DataBend The Open Source Cloud Warehouse for Everyone

Databend is inspired by apache-arrow and allows you to scale your cloud warehousing, using off the shelf open source stacks & the ultra fast processing speeds you come to expect from say Bigquery

Say Hello To DataBend The Open Source Cloud Warehouse for Everyone

Bespoke protocol and high-level implementation of Non-fungible token (NFT) technology 🚀

This project is duel-licensed under both the Apache licenses, so feel free to use either at your discretion

Bespoke protocol and high-level implementation of Non-fungible token (NFT) technology 🚀

Bespoke protocol and high-level implementation of Non-fungible token (NFT) technology 🚀

This project is duel-licensed under both the Apache licenses, so feel free to use either at your discretion

Bespoke protocol and high-level implementation of Non-fungible token (NFT) technology 🚀
Facebook Instagram Twitter GitHub Dribbble
Privacy