Hacker News new | ask | show | jobs
by stphantom 2971 days ago
Do you mean "rump kernels" or "Rumprun kernel"?

The former is a set of kernel libraries derived from NetBSD, and the latter is a Unikernel built based on the former. gVisor is different in a couple of ways: 1) gVisor is written from scratch using Go for its memory and type safety; 2) gVisor tends to be compatible with Linux which most people use. In theory, gVisor can be restructured as a Unikernel, but we still like to pertain the ring privilege boundary for additional isolation. We are working on an academic paper which will have more details.

I work on gVisor (TL/M and Co-Founder).
1 comments
_0w8t 2971 days ago
Go is not memorysafe unless one restricts the application to single CPU thread. Is it done in gVisor?
link
staticassertion 2971 days ago
This is true, Go is not memory safe in the presence of data races, and data races are possible in safe Go.

But they're also generally easy to code-review out. There's definitely a huge difference between C and Go, regardless of this one caveat to Go's memory safety guarantees.

They aren't using single threaded Go from what I can see.

link
pcwalton 2971 days ago
Data races are not easy to "code review out". That is contrary to decades of experience. All you have to do in Go to get a race is to close over a for loop induction variable in a goroutine.

There is not a large difference between C and Go here. In fact, races might be easier in Go than in C, because it's easier for goroutines to close over mutable variables.

link
staticassertion 2971 days ago
> That is contrary to decades of experience.

In languages like C and C++.

I haven't really seen this as a big problem in Go. I know of one vulnerability involving this, personally. I haven't gone looking though.

Regardless, I think there's a world of difference between C and Go when it comes to memory safety.

link
pcwalton 2971 days ago
> I haven't really seen this as a big problem in Go.

Go certainly does have problems with data races all the time. Just Google for "golang data race": you'll find many blog posts explaining common data race gotchas in Go.

> Regardless, I think there's a world of difference between C and Go when it comes to memory safety.

Agreed.

link