Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Building a Linux Container Runtime from Scratch

edera.dev

Post reply on HN
Print view View original

31–40 of 70 posts

Re: Building a Linux Container Runtime from Scratch

#31

Post by denhamparry »

r3trohack3r wrote: post #3
pzmarzly wrote: post #2

Why not use any of the existing OCI Runtimes? They take well-defined[0] JSON description as input, and are pretty well-contained (single static binary). And because they are separate binaries, not libraries, you don't need to worry about things like thread safety or FD leaking. [0] https://github.com/opencontainers/runtime-spec/blob/main/con...

I’m currently exploring this for an AI context because I haven’t found a better solution for letting K8S manage AI workloads that need direct GPU access on OSx

Edera developer here. Edera Protect is being developed to manage access to the GPU hardware on a Node with the containers running your workloads. We talk a lot about isolation between containers, but we're also focused on adding this isolation throughout the stack, from containers/processes down to hardware.

Re: Building a Linux Container Runtime from Scratch

#32

Post by denhamparry »

m00dy wrote: post #15

We are an algorithmic trading company [0], and our trading strategies are primarily built as pure Rust libraries. We've been searching for a way to sandbox the strategies we host, as not all of them are signed or open source for verification. Styrolite seems like a promising solution to address this issue, so we’re planning to give it a try. [0]: https://cycletop.xyz

Edera developer here! Thank you for sharing and any feedback you have would be great! Edera Protect is written in Rust too, and our focus is also performance as well as isolation.

Re: Building a Linux Container Runtime from Scratch

#33

Post by denhamparry »

z3t4 wrote: post #26
Joker_vD wrote: post #19

> Importantly, we designed Styrolite with full awareness that Linux namespaces were never intended as hard security boundaries—a fact that explains why container escape vulnerabilities continue to emerge. Our approach acknowledges these limitations while providing a more robust foundation. So what do you do, exactly?

Once you have set up the namespaces you drop all capabilities so if the program gets hacked while it's running it can do very little.

Edera developer here. I agree! But there are instances we need to run with additional capabilities, and we’re also dependent on people knowing how to do the right thing. We’re trying to improve this by setting this by default, but also improving the overall performance and efficiency of running containers

Re: Building a Linux Container Runtime from Scratch

#34

Post by znpy »

z3t4 wrote: post #26
Joker_vD wrote: post #19

> Importantly, we designed Styrolite with full awareness that Linux namespaces were never intended as hard security boundaries—a fact that explains why container escape vulnerabilities continue to emerge. Our approach acknowledges these limitations while providing a more robust foundation. So what do you do, exactly?

Once you have set up the namespaces you drop all capabilities so if the program gets hacked while it's running it can do very little.

honest question: how is this any better than running non-root containers?

They can do very little anyway, that way.

Re: Building a Linux Container Runtime from Scratch

#35

Post by znpy »

denhamparry wrote: post #29
Joker_vD wrote: post #25

Earlier quoted context omitted.

No, I mean, what do the Edera developers do differently, in order to provide more robust foundation with this new container runtime called Styrolite? They still use Linux namespaces, as far as I can tell from TFA.

Edera developer here, we use Styrolite to run containers with Edera Protect. Edera Protect creates Zones to isolate processes from other Zones so that if someone were to break out of a container, they'd only see the zone processes. Not the host operating system or the hardware on the machine. The key difference here between us and other isolation implementations is that there is no performance degradation, you don't…

> Edera Protect creates Zones to isolate processes from other Zones

What do you mean by "zone" exactly?

Re: Building a Linux Container Runtime from Scratch

#36

Post by xmodem »

denhamparry wrote: post #29
Joker_vD wrote: post #25

Earlier quoted context omitted.

No, I mean, what do the Edera developers do differently, in order to provide more robust foundation with this new container runtime called Styrolite? They still use Linux namespaces, as far as I can tell from TFA.

Edera developer here, we use Styrolite to run containers with Edera Protect. Edera Protect creates Zones to isolate processes from other Zones so that if someone were to break out of a container, they'd only see the zone processes. Not the host operating system or the hardware on the machine. The key difference here between us and other isolation implementations is that there is no performance degradation, you don't…

What underlying primitives are you relying on to provide isolation, if not linux namespaces?

How does your approach compare to Google's gVisor?

Re: Building a Linux Container Runtime from Scratch

#37

Post by flkenosad »

Joker_vD wrote: post #19

> Importantly, we designed Styrolite with full awareness that Linux namespaces were never intended as hard security boundaries—a fact that explains why container escape vulnerabilities continue to emerge. Our approach acknowledges these limitations while providing a more robust foundation. So what do you do, exactly?

Anyone know if it's possible to update the Linux kernel so that namespaces are hard security boundaries? I wonder what that would entail.

Re: Building a Linux Container Runtime from Scratch

#38

Post by sys_call »

znpy wrote: post #34
z3t4 wrote: post #26

Earlier quoted context omitted.

Once you have set up the namespaces you drop all capabilities so if the program gets hacked while it's running it can do very little.

honest question: how is this any better than running non-root containers? They can do very little anyway, that way.

Non-root containers still operate under a shared kernel. Non-root containers that run under a vulnerable kernel can lead to privilege escalation and container escapes.

Styrolite is a container runtime engine that runs containers in a virtual machine guest environment with no shared kernel state. It uses a type 1 hypervisor to fully isolate a running container from the node and other containers. It's similar to Firecracker or Kata containers, but doesn't require bare metal instances (runs on standard EC2, etc) and utilizes paravirtualization.

Re: Building a Linux Container Runtime from Scratch

#39

Post by sys_call »

xmodem wrote: post #36
denhamparry wrote: post #29

Earlier quoted context omitted.

Edera developer here, we use Styrolite to run containers with Edera Protect. Edera Protect creates Zones to isolate processes from other Zones so that if someone were to break out of a container, they'd only see the zone processes. Not the host operating system or the hardware on the machine. The key difference here between us and other isolation implementations is that there is no performance degradation, you don't…

What underlying primitives are you relying on to provide isolation, if not linux namespaces? How does your approach compare to Google's gVisor?

gVisor emulates a kernel in userspace, providing some isolation but still relying on a shared host kernel. The recent Nvidia GPU container toolkit vulnerability was able to privilege escalate and container escape to the host because of a shared inode.

Styrolite runs containers in a fully isolated virtual machine guest with its own, non-shared kernel, isolated from the host kernel. Styrolite doesn't run a userspace kernel that traps syscalls; it runs a type 1 hypervisor for better performance and security. You can read more in our whitepaper: http://arxiv.org/abs/2501.04580

Re: Building a Linux Container Runtime from Scratch

#40

Post by sys_call »

cedws wrote: post #17

Isn’t the gold standard of containerisation gVisor? Can’t get much more restrictive than proxying and filtering syscalls. As far as I remember it’s the default runtime on GKE.

gVisor runs a userspace kernel that proxies syscalls to a shared host kernel. Running an "application kernel" in userspace impacts performance because it goes through two schedulers. Virtual machine isolation is more restrictive because it doesn't share any kernel state with other containers. We have a whitepaper that compares the performance of gVisor and Stylorite/Edera if you want to see the differences http://arxiv.org/abs/2501.04580
Post reply on HN