News for hackers. Stuff that matters.
Re:Hyperlight: Virtual machine-based security for functions ... by fwsgonzo on Friday November 08, 2024 @12:33PM (#42088697)
Looks like my TinyKVM project, except it runs specialized programs instead of regular ELFs? TinyKVM also runs functions, with a fast execution timeout. I proved that without I/O you can essentially run KVM programs with native performance, and sometimes more due to automatic hugepages. I measured LLMs to run at 99.7% native speed using eg. Mistral 7B. For example, the STREAM memory benchmark doesn't use hugepages by default, and so the terminal version runs slower than the TinyKVM version due to hugepage-tables, but of course runs at the same speed once you modify the benchmark to use the same advantage. However, it does require modifying the program.

See: https://ieeexplore.ieee.org/document/10475832

I also implemented VM resets using page-table rewrites and CoW memory sharing, so that no memory is shared across different requests. This can be implemented as tail-latency in a cache.

I ended up adding support for most languages. All the systems languages, Go, v8, LuaJit etc. Go was by far the most annoying to support as it uses signals.

Re:Hyperlight: Virtual machine-based security for functions ... by intelVISA on Friday November 08, 2024 @09:45PM (#42092193)
Nice project, yeah this looks like a hobbled (in true MS fashion) version of TinyKVM!

Were you inspired by includeOS, Mirage, or similar?

Re:Hyperlight: Virtual machine-based security for functions ... by fwsgonzo on Saturday November 09, 2024 @03:19AM (#42093217)
I wrote the IncludeOS kernel bits
Re:Hyperlight: Virtual machine-based security for functions ... by zekrioca on Saturday November 09, 2024 @12:57AM (#42092762)
Wouldn’t containers provide the same effect as TinyKVM?
Re:Hyperlight: Virtual machine-based security for functions ... by fwsgonzo on Saturday November 09, 2024 @03:19AM (#42093222)
Yes, if you don't need sandboxing then containers are just way easier to deal with. Although I wish they didn't use so much space.
Re:Hyperlight: Virtual machine-based security for functions ... by zekrioca on Saturday November 09, 2024 @04:14AM (#42093402)
Why couldn’t one mathematically recreate the limitations of a VM through a namespace by means of SELinux?
Re:Hyperlight: Virtual machine-based security for functions ... by kevincox on Sunday November 10, 2024 @06:34AM (#42099665)
Because the Linux kernel is incredibly complicated and shouldn't be trusted as a strong security boundary. A simple hypervisor likes has far fewer vulnerabilities so is an easier to trust boundary. They are in very different security tiers.

I would summarize as containers are good for mostly trusted isolation (teams within a company, purchased software) VMs are good for general untrusted software (different tenants in a cloud provider) and separate physical hardware is for scenarios where attacks are likely (military, known malicious code). Of course use cases are very fuzzy, but I wouldn't run fully untrusted code in the same kernel as anything of value.

Re:Hyperlight: Virtual machine-based security for functions ... by generalizations on Sunday November 10, 2024 @10:48AM (#42100765)
I don't have access to that paper - and when I looked for TinyKVM all I found was the rpi-based project that uses the other definition of KVM. Is your project online somewhere? Or is it proprietary?
Re:Hyperlight: Virtual machine-based security for functions ... by fwsgonzo on Sunday November 10, 2024 @01:10PM (#42101561)
I can't publish/open-source it, sadly. But the paper I can share: https://www.dropbox.com/scl/fi/38e0la5m6zkc04tlm03w8/Introdu...
Re:Hyperlight: Virtual machine-based security for functions ... by generalizations on Monday November 11, 2024 @11:13AM (#42108196)
That's cool. Thanks dude.
Re:Hyperlight: Virtual machine-based security for functions ... by bjconlan on Wednesday November 13, 2024 @02:05AM (#42123595)
Also appreciate the reference. I just realized you're the libriscv author (and as pointed out includeOS contributor). Love all your work!