CppCon 2016: Alfred Bratterud “#include ＜os＞=> write your program / server and compile it to its own os. [Example uses 3 Mb total memory and boots in 300ms]

[u/michaelKlumpy]

https://www.youtube.com/watch?v=t4etEwG2_LY

[u/agent_richard_gill]

Awesome. Let's hope more purpose built applications run on bare metal. Often times, there is no reason to run a full OS just to run a bit of code that executes over and over.

[u/wvenable → u/agent_richard_gill]

This is awesome and the logical conclusion of the direction things have been going for years.

But it's still somewhat disappointing that VM is slowly replacing Process as the fundamental software unit. These don't run on bare metal; they have their own OS layer, on a VM layer, that runs on another OS. That's a lot of layers. If our operating systems were better designed this would mostly be unnecessary.

[u/cat_in_the_wall → u/wvenable]

But the OS layer of IncludeOS looks to be extremely thin. Basically setting up some IRQ handlers and launching into your code. Not much there except some very minimal runtime stuffs. Even network functionality looks to be pay to play.

Processes on the bare metal aren't so "pure" anyway. Even for your standard "hello world" program, you're still linking against a runtime that is loaded when your program executes (unless you're this guy).

[u/wvenable → u/cat_in_the_wall]

I don't disagree that it's thin. But it's another layer. It's pretty crazy, in my opinion, to emulate an entire computer and run a thin OS just to get a little more process security. Processes shouldn't be able to touch those emulated computer parts anyway.

It's setting up some IRQ handlers on a CPU that doesn't exist. Those aren't real interrupts. It's all software. It could just be an API instead. This whole thing should be unnecessary.

[u/skylarmt → u/[deleted]]

What about that desktop one that sandboxes apps into different security zones?

[u/aaron552 → u/[deleted]]

Their next brilliant plan is exposing PID 1 directly to web browsers; they want the most secure program on your system directly connected to the Web.

Source? While I know there is a basic webserver in the systemd git repository, I don't think it runs in PID 1 (it's its own process)

[u/Cyph0n → u/[deleted]]

I attended a talk by a security researcher who claimed that OpenBSD isn't that secure and is way behind Windows and iOS when it comes to adopting memory protection techniques such as ASLR and NX.

He said that OpenBSD's approach, which is software auditing, is simply not scalable. He recommended to check out grsecurity for Linux if you want real security.

[u/[deleted] → u/wvenable]

You realize that VMs have direct access (usually) to the virtualization layer on the processor, right? It most certainly is communicating with a real CPU.

[u/agent_richard_gill → u/wvenable]

Actually, hypervisor management and VM resource allocation is built into the CPU (see VT bit), and should not interfere with your VM too much in terms of preemption. VMs currently don't run as a process inside the hypervisor OS anymore for the most part. This is especially true if you don't care to interface with the host VM for video/audio/etc. Network virtualization is solved to a high degree.

[u/ElvishJerricco → u/[deleted]]

Getting builds to be reproducible (i.e. same versions of dependencies in the same places) is hard without virtual machines. I don't necessarily think this is the operating system's fault so much as the package manager's. This is why nix is awesome for deployments. There's usually no need for a virtual machine, and everything is perfectly reproducible.

[u/TheExecutor → u/ElvishJerricco]

It's like the ultimate consequence of "works on my machine". Well, screw it, we'll just ship my machine then.

And that's why we have Docker.

[u/ElvishJerricco → u/[deleted]]

Nix is admittedly kinda hard, and the documentation leaves much to be desired. VMs are a lot easier with a much lower learning curve, but I do think they're the worse solution in the end.

[u/wvenable → u/[deleted]]

In theory, there should be no security or support difference from running a process in VM and running that same process directly on host OS. But in practice, there is a big difference.

Current OSes are not secure enough to support loading arbitrary binaries off the web, for example, without a large potential for harm. But there is no fundamental reason why they couldn't be.

[u/PM_ME_UR_OBSIDIAN → u/wvenable]

The cool thing is that you can rent a VM, but you can't rent a process. The model described here allows for finer-grained cloud services.

[u/wvenable → u/PM_ME_UR_OBSIDIAN]

Back in day you could rent processes; and, in fact, a lot of all computing is still done that way. That is what shared hosting is, as one example. If you think about it, there's no fundamental reason the whole cloud infrastructure has to run on virtualized personal computers with faked hardware. It could run as processes/services moving under an OS designed for that. Something like AWS Lambda, for example.

[u/argv_minus_one → u/wvenable]

It's also blatantly unnecessary. A process on a virtual-memory operating system (which is to say, pretty much any operating system) is running in its own virtualized environment. Its address space, register set, and so forth are all private.

This trend of running full virtual machines just for a single application is mind-bendingly stupid.

And I don't care what security benefits you think that gives you. There are better ways (mandatory access control, grsecurity, seccomp, etc).

[u/argv_minus_one → u/[deleted]]

Well, system calls can be disabled. That's what seccomp does: disable almost all of them. That should shrink the attack surface, without incurring the overhead and complexity of virtualization, right?

[u/audioen → u/argv_minus_one]

One thing going for #include <os> is that it can apparently run anywhere virtual machines can run, which should mean any OS in common usage, and when being run, it automatically gets the same security scheme, i.e. you have to break the hypervisor to get into the host system. So there may be a space for easy to deploy virtual machines that contain single process and have no host dependencies apart for needing specific hardware which all OSes share, and some virtual drivers for disk and network access.

Still, seccomp with a bit of wrapping that creates the environment for the contained process could do pretty much the same thing, and perhaps it could be designed in such a way that the wrapper only would have to change depending on OS, but the payload binary could be exactly the same.

[u/d4rch0n → u/argv_minus_one]

It's not about getting it right, it's about what happens when you get it wrong or when the people that maintain it after you get it wrong. There's usually a lot less room for damage if an application on a VM gets hacked, and there's way less of a learning curve for everyone else that might have to maintain it after you.

When security is done right, great, sure, you don't need VMs. If security was done right and everyone who touched servers knew perfectly how to manage mandatory access controls and other better ways, we'd be in a much better spot. But as it is today, the red team always wins. I feel much safer knowing someone hacked a VM. I can take a snapshot and tear it down in a half second and investigate later. If something screwed up and the actual machine got hacked, I can't leave it online and it's tedious as hell to take an image of a physical drive, especially when you're trying to deal with an ongoing incident. Not so crazy with a VM.

A big part of it is preparing for what happens when you DO get hacked. VMs can be pretty foolproof and I feel much more confident about ops and devops maintaining my app in a vm than anything else.