[HN Gopher] Hyperlight: Virtual machine-based security for funct...
___________________________________________________________________
Hyperlight: Virtual machine-based security for functions at scale
Author : yoshuaw
Score : 42 points
Date : 2024-11-07 17:01 UTC (5 hours ago)
(HTM) web link (opensource.microsoft.com)
(TXT) w3m dump (opensource.microsoft.com)
| yoshuaw wrote:
| The Azure Upstream team has been working on a really fast
| hypervisor library written in Rust for the past three years. It
| does less than you'd conventionally do with hypervisors, but in
| turn it can start VMs around 2 orders of magnitude faster (around
| 1-2ms/VM).
|
| I think this is really cool, and the library was just released on
| GitHub for anyone to try. I'm happy I got to help them write
| their announcement post -- and I figured this might be
| interesting for folks here!
| dangoodmanUT wrote:
| Do you think requiring to use their packages is too limiting
| for widespread usage? Seems like you're forced to use Rust or C
| atm.
|
| This seems like a limitation that sits in a somewhat unusable
| place: For something simple and platform-specific (e.g. a HTTP
| transform) we can just use JS where the boot time perf makes up
| for the execution perf, and for something more serious like a
| full-fledged API 120ms should be more than enough time (and we
| can preemtively scale as long as we're not already at 0)
| generalizations wrote:
| > These micro VMs operate without a kernel or operating system,
| keeping overhead low. Instead, guests are built specifically for
| Hyperlight using the Hyperlight Guest library, which provides a
| controlled set of APIs that facilitate interaction between host
| and guest
|
| Sounds like this is closer to a chroot/unikernel than a "micro
| VM" - a slightly more firewalled chroot without most of the os
| libs, or a unikernel without the kernel. Pretty sure it's not a
| "virtual machine" though.
|
| Only pointing this out because these sorts of
| containers/unikernels/vms exist on a spectrum, and each type
| carries its own strengths and limitations; calling this by the
| wrong name associates it with the wrong set of tradeoffs.
| wmf wrote:
| I guess if it uses CR3 it's a "process" and if it uses VMLAUNCH
| it's a "VM".
| generalizations wrote:
| Heh. Going by that delineation we end up with very VM-ish
| containers and (now) very container-ish VMs. Though this
| seems like it's even more stripped down than a unikernel -
| which would also be a "VM" here.
| 0cf8612b2e1e wrote:
| I thought a chroot was not considered a real security boundary?
| ronsor wrote:
| Chroot is a real security boundary as long as you use it
| properly. That said, namespaces on Linux are much superior at
| this point, so I can only recommend using `chroot` for POSIX
| compliance.
| apitman wrote:
| Don't see any mention of firecracker, which is the first thing I
| think of in this space. Anyone have a TL;DR comparison?
| eyberg wrote:
| Firecracker can run ordinary linux/GPOS vms and unikernels.
|
| Unikernels can run inside of firecracker.
|
| Unikernels are focused on single applications whereas general
| purpose operating systems are focused on multiple applications.
|
| This is focused on running _functions_ embedded inside a host
| program. So it is fairly different than other things out there
| and in a class of its own.
| ATechGuy wrote:
| > each function request to have its own hypervisor for
| protection.
|
| They are talking about isolating serverless functions, not
| host program functions. In that sense, it is exactly what
| Firecracker does for lambda functions
___________________________________________________________________
(page generated 2024-11-07 23:00 UTC)