[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-84168":3},{"id":4,"name":5,"fullName":6,"owner":5,"repo":5,"description":7,"homepage":8,"htmlUrl":9,"language":10,"languages":8,"totalLinesOfCode":8,"stars":11,"forks":12,"watchers":13,"openIssues":14,"contributorsCount":8,"subscribersCount":15,"size":15,"stars1d":16,"stars7d":17,"stars30d":17,"stars90d":15,"forks30d":15,"starsTrendScore":18,"compositeScore":19,"rankGlobal":8,"rankLanguage":8,"license":8,"archived":20,"fork":20,"defaultBranch":21,"hasWiki":20,"hasPages":20,"topics":8,"createdAt":8,"pushedAt":8,"updatedAt":22,"readmeContent":23,"aiSummary":8,"trendingCount":15,"starSnapshotCount":15,"syncStatus":24,"lastSyncTime":25,"discoverSource":26},84168,"libkrun","libkrun\u002Flibkrun","A dynamic library providing Virtualization-based process isolation capabilities",null,"https:\u002F\u002Fgithub.com\u002Flibkrun\u002Flibkrun","Rust",2310,204,30,51,0,8,10,26,28.94,false,"main","2026-06-12 02:04:38","\u003Cpicture>\n   \u003Csource media=\"(prefers-color-scheme: dark)\" srcset=\"docs\u002Fimages\u002Flibkrun_logo_horizontal_darkmode.png\">\n   \u003Csource media=\"(prefers-color-scheme: light)\" srcset=\"docs\u002Fimages\u002Flibkrun_logo_horizontal.png\">\n   \u003Cimg alt=\"libkrun logo\" src=\"docs\u002Fimages\u002Flibkrun_logo_horizontal_200.png\">\n\u003C\u002Fpicture>\n\n# libkrun\n\n```libkrun``` is a dynamic library that allows programs to easily acquire the ability to run processes in a partially isolated environment using [KVM](https:\u002F\u002Fwww.kernel.org\u002Fdoc\u002FDocumentation\u002Fvirtual\u002Fkvm\u002Fapi.txt) Virtualization on Linux and [HVF](https:\u002F\u002Fdeveloper.apple.com\u002Fdocumentation\u002Fhypervisor) on macOS\u002FARM64.\n\nIt integrates a VMM (Virtual Machine Monitor, the userspace side of an Hypervisor) with the minimum amount of emulated devices required to its purpose, abstracting most of the complexity that comes from Virtual Machine management, offering users a simple C API.\n\n## Use cases\n\n* [crun](https:\u002F\u002Fgithub.com\u002Fcontainers\u002Fcrun\u002Fblob\u002Fmain\u002Fkrun.1.md): Adding Virtualization-based isolation to container and confidential workloads.\n* [krunkit](https:\u002F\u002Fgithub.com\u002Fcontainers\u002Fkrunkit): Running GPU-enabled (via [venus](https:\u002F\u002Fdocs.mesa3d.org\u002Fdrivers\u002Fvenus.html)) lightweight VMs on macOS.\n* [muvm](https:\u002F\u002Fgithub.com\u002FAsahiLinux\u002Fmuvm): Launching a microVM with GPU acceleration (via [native context](https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=9sFP_yddLLQ)) for running games that require 4k pages.\n\n## Goals and non-goals\n\n### Goals\n\n* Enable other projects to easily gain KVM-based process isolation capabilities.\n* Be self-sufficient (no need for calling to an external VMM) and very simple to use.\n* Be as small as possible, implementing only the features required to achieve its goals.\n* Have the smallest possible footprint in every aspect (RAM consumption, CPU usage and boot time).\n* Be compatible with a reasonable amount of workloads.\n\n### Non-goals\n\n* Become a generic VMM.\n* Be compatible with all kinds of workloads.\n\n## Variants\n\nThis project provides the following variants of the library:\n\n- **libkrun**: Generic variant compatible with all Virtualization-capable systems.\n- **libkrun-sev**: Variant including support for AMD SEV (SEV, SEV-ES and SEV-SNP) memory encryption and remote attestation. Requires an SEV-capable CPU.\n- **libkrun-tdx**: Variant including support for Intel TDX memory encryption. Requires a TDX-capable CPU.\n\nEach variant generates a dynamic library with a different name (and ```soname```), so both can be installed at the same time in the same system.\n\n## Virtio device support\n\n### All variants\n\n* virtio-console\n* virtio-block\n* virtio-fs\n* virtio-gpu (venus and native-context)\n* virtio-net\n* virtio-vsock (for TSI and socket redirection)\n* virtio-balloon (only free-page reporting)\n* virtio-rng\n\n\n## Networking\n\nIn ```libkrun```, networking is provided by two different, mutually exclusive techniques: **virtio-vsock + TSI** and **virtio-net + passt\u002Fgvproxy**.\n\n### virtio-vsock + TSI\n\nThis is a novel technique called **Transparent Socket Impersonation** which allows the VM to have network connectivity without a virtual interface. This technique supports both outgoing and incoming connections. It's possible for userspace applications running in the VM to transparently connect to endpoints outside the VM and receive connections from the outside to ports listening inside the VM.\n\n#### Enabling TSI\n\nTSI for AF_INET and AF_INET6 is automatically enabled when no network interface is added to the VM. TSI for AF_UNIX is enabled when, in addition to the previous condition, `krun_set_root` has been used to set `\u002F` as root filesystem.\n\n#### Known limitations\n\n- Requires a custom kernel (like the one bundled in **libkrunfw**).\n- It's limited to SOCK_DGRAM and SOCK_STREAM sockets and AF_INET, AF_INET6 and AF_UNIX address families (for instance, raw sockets aren't supported).\n- Listening on SOCK_DGRAM sockets from the guest is not supported.\n- When TSI is enabled for AF_UNIX sockets, only absolute path are supported as addresses.\n\n### **virtio-net + passt\u002Fgvproxy**\n\nA conventional virtual interface that allows the guest to communicate with the outside through the VMM using a supporting application like [passt](https:\u002F\u002Fpasst.top\u002Fpasst\u002Fabout\u002F) or [gvproxy](https:\u002F\u002Fgithub.com\u002Fcontainers\u002Fgvisor-tap-vsock).\n\n#### Enabling virtio-net\n\nUse `krun_add_net_unixstream` and\u002For `krun_add_net_unixdgram` to add a virtio-net interface connected to the userspace network proxy.\n\n## Security model\n\nThe libkrun security model is primarily defined by the consideration that both the guest and the VMM pertain to the same security context. For many operations, the VMM acts as a proxy for the guest within the host. Host resources that are accessible to the VMM can potentially be accessed by the guest through it.\n\nWhile defining the security implementation of your environment, you should think about the guest and the VMM as a single entity. To prevent the guest from accessing host's resources, you need to use the host's OS security features to run the VMM inside an isolated context. On Linux, the primary mechanism to be used for this purpose is namespaces. Single-user systems may have a more relaxed security policy and just ensure the VMM runs with a particular UID\u002FGID.\n\nWhile most virtio devices allow the guest to access resources from the host, two of them require special consideration when used: virtio-fs and virtio-vsock+TSI.\n\n### virtio-fs\n\nWhen exposing a directory in a filesystem from the host to the guest through virtio-fs devices configured with `krun_set_root` and\u002For `krun_add_virtiofs`, libkrun **does not** provide any protection against the guest attempting to access other directories in the same filesystem, or even other filesystems in the host.\n\nA mount point isolation mechanism from the host should be used in combination with virtio-fs.\n\nIn addition, when using virtio-fs, a guest may exhaust filesystem resources such as inode limits and disk capacity. Controls should be implemented on the host to mitigate this.\n\n### virtio-vsock + TSI\n\nWhen TSI is enabled, the VMM acts as a proxy for AF_INET, AF_INET6 and AF_UNIX sockets, for both incoming and outgoing connections. For all that matters, the VMM and the guest should be considered to be running in the network context. As such, you should apply on the VMM whatever restrictions you want to apply on the guest.\n\n## Building and installing\n\n### Linux\n\n#### Requirements\n\n* [libkrunfw](https:\u002F\u002Fgithub.com\u002Fcontainers\u002Flibkrunfw)\n* A working [Rust](https:\u002F\u002Fwww.rust-lang.org\u002F) toolchain\n* C Library static libraries, as the [init](init\u002Finit.c) binary is statically linked (package ```glibc-static``` in Fedora)\n* patchelf\n\n#### Optional features\n\n* **GPU=1**: Enables virtio-gpu. Requires virglrenderer-devel.\n* **VIRGL_RESOURCE_MAP2=1**: Uses virgl_resource_map2 function. Requires a virglrenderer-devel patched with [1374](https:\u002F\u002Fgitlab.freedesktop.org\u002Fvirgl\u002Fvirglrenderer\u002F-\u002Fmerge_requests\u002F1374)\n* **BLK=1**: Enables virtio-block.\n* **NET=1**: Enables virtio-net.\n\n\n#### Compiling\n\n```\nmake [FEATURE_OPTIONS]\n```\n\n#### Installing\n\n```\nsudo make [FEATURE_OPTIONS] install\n```\n\n### Linux (SEV variant)\n\n#### Requirements\n\n* The SEV variant of [libkrunfw](https:\u002F\u002Fgithub.com\u002Fcontainers\u002Flibkrunfw), which provides a ```libkrunfw-sev.so``` library.\n* A working [Rust](https:\u002F\u002Fwww.rust-lang.org\u002F) toolchain\n* C Library static libraries, as the [init](init\u002Finit.c) binary is statically linked (package ```glibc-static``` in Fedora)\n* patchelf\n* OpenSSL headers and libraries (package ```openssl-devel``` in Fedora).\n\n#### Compiling\n\n```\nmake SEV=1\n```\n\n#### Installing\n\n```\nsudo make SEV=1 install\n```\n\n### Linux (TDX variant)\n\n#### Requirements\n\n* The TDX variant of [libkrunfw](https:\u002F\u002Fgithub.com\u002Fcontainers\u002Flibkrunfw), which provides a ```libkrunfw-tdx.so``` library.\n* A working [Rust](https:\u002F\u002Fwww.rust-lang.org\u002F) toolchain\n* C Library static libraries, as the [init](init\u002Finit.c) binary is statically linked (package ```glibc-static``` in Fedora)\n* patchelf\n* OpenSSL headers and libraries (package ```openssl-devel``` in Fedora).\n\n#### Compiling\n\n```\nmake TDX=1\n```\n\n#### Installing\n\n```\nsudo make TDX=1 install\n```\n\n#### Limitations\n\nThe TDX flavor of libkrun only supports guests with 1 vCPU and memory less than or equal to 3072mib.\n\n### macOS\n\n#### Requirements\n\n* A working [Rust](https:\u002F\u002Fwww.rust-lang.org\u002F) toolchain\n* A host running macOS 14 or newer\n* Homebrew packages `lld` and `xz`\n\n#### Compiling\n\n```\nmake [FEATURE_OPTIONS]\n```\n\nThe [init](init\u002Finit.c) binary is cross-compiled using clang and lld.\nA suitable sysroot is automatically generated by the Makefile from Debian repository.\n\n#### Installing\n\n```\nsudo make [FEATURE_OPTIONS] install\n```\n\n## Using the library\n\nDespite being written in Rust, this library provides a simple C API defined in [include\u002Flibkrun.h](include\u002Flibkrun.h)\n\n## Examples\n\n### chroot_vm\n\nThis is a simple example providing ```chroot```-like functionality using ```libkrun```.\n\n#### Building chroot_vm\n\nTo be able to ```chroot_vm```, you need need to build libkrun with the `virtio-block` and `virtio-net` optional features:\n\n```\nmake BLK=1 NET=1\nsudo make BLK=1 NET=1 install\ncd examples\nmake\n```\n\n#### Running chroot_vm\n\nTo be able to ```chroot_vm```, you need first a directory to act as the root filesystem for your isolated program.\n\nUse the ```rootfs``` target to get a rootfs prepared from the Fedora container image (note: you must have [podman](https:\u002F\u002Fpodman.io\u002F) installed):\n\n```\nmake rootfs\n```\n\nNow you can use ```chroot_vm``` to run a process within this new root filesystem:\n\n```\n.\u002Fchroot_vm .\u002Frootfs_fedora \u002Fbin\u002Fsh\n```\n\nIf the ```libkrun``` and\u002For ```libkrunfw``` libraries were installed on a path that's not included in your ```\u002Fetc\u002Fld.so.conf``` configuration, you may get an error like this one:\n\n```\n.\u002Fchroot_vm: error while loading shared libraries: libkrun.so: cannot open shared object file: No such file or directory\n```\n\nTo avoid this problem, use the ```LD_LIBRARY_PATH``` environment variable to point to the location where the libraries were installed. For example, if the libraries were installed in ```\u002Fusr\u002Flocal\u002Flib64```, use something like this:\n\n```\nLD_LIBRARY_PATH=\u002Fusr\u002Flocal\u002Flib64 .\u002Fchroot_vm rootfs_fedora\u002F \u002Fbin\u002Fsh\n```\n\n## Contributing\n\nSee [CONTRIBUTING.md](CONTRIBUTING.md) for guidelines on submitting changes.\n\n## Status\n\n```libkrun``` has achieved maturity and starting version ```1.0.0``` the public API is guaranteed to be stable, following [SemVer](https:\u002F\u002Fsemver.org\u002F).\n\n## Getting in contact\n\nIf you think you've identified a security issue in the project, please DO NOT report the issue publicly via the GitHub issue tracker or Matrix. Instead, send an email with as many details as possible to `libkrun-security@redhat.com`. This is a private mailing list for the core maintainers.\n\nThe main communication channel is the [libkrun Matrix channel](https:\u002F\u002Fmatrix.to\u002F#\u002F#libkrun:matrix.org).\n\n## Acknowledgments\n\n```libkrun``` incorporates code from [Firecracker](https:\u002F\u002Fgithub.com\u002Ffirecracker-microvm\u002Ffirecracker), [rust-vmm](https:\u002F\u002Fgithub.com\u002Frust-vmm\u002F) and [Cloud-Hypervisor](https:\u002F\u002Fgithub.com\u002Fcloud-hypervisor\u002F).\n",2,"2026-06-11 04:12:27","trending"]