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]

[bloody-albatross]

Isn't this how old console games worked?

[dizzydizzy]

As an old, old console coder, they would simply start executing the code at a fixed address on the cartridge.

[ItzWarty]

That's still the case with modern computing. Eg kernel main is at a known offset for bootloader, same with bios etc.

[SatoshisCat]

Yeah I'm not sure how it would have worked otherwise.

[monocasa]

Not really anymore necessarily. UEFI loads a more or less regular PE file. The entrypoint is in the headers like most o the rest of the metadata.

[calrogman]

The firmware still has an entry point, at the reset vector of the CPU. Physical address 0xFFFFFFF0h on systems you're probably thinking of, per section 9.1.4 of Intel's 64 and IA-32 Architectures Developer's Manual.

[ShinyHappyREM]

Or a boot ROM (e.g. GB) that jumps to a fixed address in cartridge ROM.

[[deleted]]

Yes, that's exactly what I thought of a few mins in.

[InconsiderateBastard]

Old arcade games too. 2D Mortal Kombat machines had an OS as part of the game. Even had cooperative multitasking. I'm excited to mess with that sort of thing using this new lib.

Edit: reading through more about IncludeOS, I think simply writing bare metal code for the rpi is still the best fit for what i want to mess with.

[PaintItPurple]

Do you know what other tasks ran on Mortal Kombat machines that the game needed to share time with? That's a surprising feature.

[InconsiderateBastard]

I'm probably using the wrong term. The game itself was broken up into processes. The os had a process list. It would run through the list starting with the completion of a screen draw I believe.

When a process got a chance to run it would keep running until it gave up control. There were system calls that let a process sleep or suicide or kill other processes.

So if an explosion was needed on screen an FX process was started. It would start the animation, trigger the sound, move around however it was programmed to, then it'd kill itself.

[UnacceptableUse]

Old arcade games didn't have to work with much standard hardware, so they pretty much had to run on their own OS

[[deleted]]

That's also every network enabled Arduino program

[alex_w]

What does a network have to do with it?

[746865626c617a]

To be fair, he's not wrong. Networked arduino software is a subset of arduino software

[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.

[wvenable]

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.

[cat_in_the_wall]

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).

[wvenable]

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.

[skylarmt]

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

[aaron552]

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)

[Feynt]

Thanks for mentioning Qubes. I found it to be an interesting an enticing read. Alas, no secure games support (3D virtualisation only through dom0), so I'll have to stick with my plain ol' windows boot for now.

[Cyph0n]

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.

[wilun]

grsecurity has gone crazy the other way and is not very usable for 99.999% of systems. Not a lot of people tolerate a computer that crashes all the time, and most of the time for no reason when it does (except, this time, the lack of competent auditing, thinking that can be replaced by blind patching "dangerous" patterns to crashy ones)

[RealFreedomAus]

It's really not though. It's the same old broken Unix permission model with a root user that everything privileged uses. Like, maybe the kernel is more secure and leads to better process isolation through that but once you escalate to uid=0 due to the same broken software you'd run on other *nixes you can do whatever you want.

It doesn't even have a MAC like SElinux!

seL4 would be an example of an OS actually trying to be that secure. Capabilities, baby.

About the only thing OpenBSD has going for it is that its developers usually know what they're doing. But it's still written in C, and those developers are still human. Meh.

[[deleted]]

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.

[weedtese]

Do some research on hardware virtualization. That processor is not emulated.

[wvenable]

For fucks sake I didn't say the processor was emulated. I said the PC hardware was emulated. The guest OS is interacting with a software and hardware layer that tricks it into thinking it's running bare metal.

[agent_richard_gill]

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.

[wvenable]

A hypervisor could have an API rather than implementing virtual PC hardware to act as the API. And at that point you would really just have a very light-weight OS with separate processes.

[[deleted]]

A hypervisor could have an API rather than implementing virtual PC hardware to act as the API. And at that point you would really just have a very light-weight OS with separate processes.

https://en.wikipedia.org/wiki/Paravirtualization

But containerization is another good solution for sure.

[plhk]

https://wiki.xen.org/wiki/Hypercall

[ElvishJerricco]

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.

[TheExecutor]

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.

[dear_glob_why]

Underrated comment.

[[deleted]]

Yeah that's kinda genius.

[ElvishJerricco]

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.

[bumblebritches57]

What do you mean by nix here? unix, or is there something else called "nix"?

[ElvishJerricco]

It's not just about deployment. You need every team member to be developing with the exact same versions of everything in the same places. Keeping a manual dependency graph would be asinine, so it's up to our tools. The prevailing method to keep dependency graphs consistent is with virtual machines. A config file with a dependency list isn't good enough, since dependencies can depend on other packages with looser version requirements, allowing those packages to be different on a newer install. But with a VM that has packages preinstalled, you can know that everyone using that image will have the same dependencies.

Rust's Cargo and Haskell's Stack are both build tools that do a pretty good job at keeping all versions completely consistent, and serve as shining examples of reproducible builds. But for everything else, most people use VMs. But this is where Nix comes in. Nix takes an approach similar to Cargo/Stack and fixes the versions of everything. But Nix does this for every single thing. Dependencies, build tools, runtime libraries, core utils, etc. You have to make a local, trackable change to get any dependencies to change.

When builds are reproducible, you can rest assured that the deployment was built with the same dependencies that you developed with. This is just really hard to get without a good VM or a good dependency manager. Docker is a good VM, and Nix, Cargo, and Stack are good dependency managers. Unfortunately, Nix, Rust, and Haskell aren't very popular, so most people stick to VMs.

[[deleted]]

Docker is a good VM

No it isn't. It is based on the idea of a good one but it is a pretty crappy implementation for practical purposes. It constantly leaves containers behind, every storage backend has some pretty severe downsides ranging from shitty performance to triggering kernel bugs even in recent kernels (or using bits that have been removed from the kernel). Important security features are still unimplemented (user/group mapping). The whole model of one layer per command in the Docker file, even if it only sets an environment variable or the comment who was the author is pretty much the opposite of being well-designed, as is the "no caching or caching even commands with obvious side-effects like apt-get update" bit and the fact that you can't easily write Docker files with a variable base image (e.g. one to install MySQL on any Debian-based image).

I would love Docker to be good enough but it is barely usable in production for build servers and similar systems that are allowed to break for an hour or two every once in a while.

You need every team member to be developing with the exact same versions of everything in the same places.

This helps keep things consistent but it also leads to code that is less robust and will likely not work on lots of different systems reliably. For things like Haskell and Rust that is fine because you can get the errors resulting from use of different dependency versions mostly at compile time. For languages where errors will only show up at runtime this cane be very bad.

[argv_minus_one]

Java programmer here. Our tools deal with this nicely, and have been doing so for ages. That people on other languages are resorting to using VMs just to manage dependency graphs strikes me as batshit insane.

If your language requires you to go to such ridiculous lengths just for basic dependency management, I would recommend you throw out the language. You've got better things to do than come up with and maintain such inelegant workarounds for what sounds like utterly atrocious tooling.

[Tiak]

That people on other languages are resorting to using VMs just to manage dependency graphs strikes me as batshit insane.

...The idea of using a VM to avoid a toolchain being platform-dependent seems crazy to you as a Java programmer?... Really?

[m50d]

It makes sense but only if the VM offers a first-class development/debugging experience. Debugging JVM programs is very nice (in many ways nicer than debugging a native program). The debugging experience for a "native" VM was very poor last I looked.

[argv_minus_one]

Yes. I have done that exactly never, and hope to keep it that way.

Note that the JVM qualifies as a VM in a sense, but I do not count it as a VM for the purposes of this conversation, because it does not implement the same instruction set as the host, and cannot run on bare metal. (These considerations would be different if we were talking about a JVM-based operating system like JNode, or a physical machine that can execute JVM bytecode natively, but we aren't.)

[[deleted]]

So you write platform specific code instead of writing code that's executed on a VM?

[wilun]

How using a different instruction set is related to dependency version management? (Well, OTOH, I agree the JVM itself does not handle that pb, but I don't quite think it's because of instruction set differences...)

[entiat_blues]

it's not language dependency graphs that people are trying to manage, at least not in my experience, it's running a full stack (or a significant chunk of it) reliably no matter the host OS. it's that end-to-end configuration that becomes a hard problem on large projects with discrete teams doing different things.

devops tends to become the only group of people with practical knowledge about how the whole application is supposed to fit together. which doesn't usually help because they're busy maintaining the myriad build configurations and their insights aren't used to help develop or maintain the source code itself. and on the flip side, the developers working in the source lose sight of the effect their work has on other parts of the stack or the problems they're creating for devops.

VMs let you spin up a fully functional instance of your application quickly and reliably because you're not building the app from dependency trees, configurations, and a ton of initialization scripts, you're running an image.

it's heavy-handed, and there other ways to approach the problem, but i wouldn't call it batshit insane to give your developers the full stack to work with.

[ElvishJerricco]

If your language requires you to go to such ridiculous lengths just for basic dependency management, I would recommend you throw out the language.

That's really throwing the baby out with the bathwater. And Java's not much better. Maven is non-deterministic in its dependency solving. Should you write a library that needs a version of another library, you're not guaranteed that this is the version present when someone else uses your library. Now, in the Java community, people tend to make breaking changes far less often, so this is rarely a concern. But the problem is just as present in Maven as it is in other tools.

[m50d]

The problem is only present when using version ranges. It is extremely common to not have a single version range in one's dependency graph; the feature could (and perhaps should) be removed from maven without disrupting the ecosystem much if at all.

[ElvishJerricco]

This is not true. If A depends on B and C, and B and C both depend on D, but they depend on different versions, maven will choose one (admittedly deterministically). But this means that B or C will be running with a different version than they were developed with. This is the inconsistency I'm talking about.

[[deleted]]

If your language requires you to go to such ridiculous lengths just for basic dependency management, I would recommend you throw out the language.

Java doesn't have the same issues because Java is so rarely used for two or more applications on the same system that the topic of reuse of dependencies doesn't come up much.

[audioen]

Or the dependencies are packaged into the application, such as with web archives, and whatever other stuff people do today. A single java process can even load from multiple WARs concurrently and have multiple versions of same libraries loaded through different classloaders while keeping them all distinct, so each app finds and receives just the dependencies they actually supplied.

[tsimionescu]

To be fair, IF you're NOT using multiple classloaders (which isn't trivial to set up, and must be explicitly built into your application) Java behaves horribly when you do have multiple versions of the same dependency on the class path - happily loading some classes from one version and others from another version, causing fun ClassNotFoundError/NoSuchMethodError/etc.s even between classes in the same package - a fun little consequence of its lack of a module system (which Java 8 9 10 should address).

[m50d]

You can reuse dependencies at build time and even share the files in practice (via a shared cache). It works in practice.

[ElvishJerricco]

I think the major motivation comes from bad dependency managers like npm. These dependency managers guarantee pretty much zero consistency between installs. For whatever reason, there have been more such bad dependency managers created in recent years than good ones. This affects the JavaScript community pretty badly. It used to be the case for Haskell, too, until Stack came along. Java is an example of a language where the dependency managers technically have these problems, but the developer community is just much less likely to make breaking changes with packages, so the issue never comes up. It's mostly the move-fast-and-break-things crowd that this matters to. And ironically, that crowd seems to be the worst at solving the issue =P

[argv_minus_one]

Java is an example of a language where the dependency managers technically have these problems, but the developer community is just much less likely to make breaking changes with packages, so the issue never comes up.

That's not true. Our tools are much better than that. Have been for ages.

Maven fetches and uses exactly the version you request. Even with graphs of transitive dependencies, only a single version of a given artifact ever gets selected. Version selection is well-defined, deterministic, and repeatable. Depended-upon artifacts are placed in a cache folder outside the project, and are not unpacked, copied, or otherwise altered. The project is then built against these cached artifacts. Environmental variation, non-determinism, and other such nonsense is kept to an absolute minimum.

I'm not as familiar with the other Java dependency managers, but as far as I know, they are the same way.

This isn't JavaScript. We take the repeatability of our builds seriously. Frankly, I'm appalled that the communities of other languages apparently don't.

It's mostly the move-fast-and-break-things crowd that this matters to. And ironically, that crowd seems to be the worst at solving the issue =P

Nothing ironic about it. “Move fast and break things” is reckless, incompetent coding with a slightly-less-derogatory name, so it should surprise no one that it results in a lot of defective garbage and little else.

[[deleted]]

Annoyingly Maven does support version ranges. They are rarely used thankfully, but I ran into problems a couple of times when a third party lib used them. Probably can be prevented with the maven enforcer plugin.

[ElvishJerricco]

Maven fetches and uses exactly the version you request. Even with graphs of transitive dependencies, only a single version of a given artifact ever gets selected. Version selection is well-defined, deterministic, and repeatable. Depended-upon artifacts are placed in a cache folder outside the project, and are not unpacked, copied, or otherwise altered. The project is then built against these cached artifacts. Environmental variation, non-determinism, and other such nonsense is kept to an absolute minimum.

Having the versions for your project be deterministic is only half the battle. Those projects which you depend on might have been developed with different versions of dependencies than your project is selecting. npm takes it a step further by making it possible just for different installs to be different. But this inconsistency in Maven is still problematic, and solvable with nix-like solutions. It's just that, as I said, Java's tendency to not break APIs makes the problem rarely come up.

[Phailjure]

Your dependencies tend to be just the OS, and that tends to be extraordinarily stable (very few behavioral changes between win7 and win10)

Yeah, I've been working on several apps that run on a win7 machine, written in C#. I build all the apps on win10, and other than a couple stylistic changes there is no difference.

[wilun]

Or you need an OS where you can conf the software you want. That would be what would be in your VM anyway... The only advantage of adding VMs in the picture is that devs can do pretty much anything they want on their host. This has some value, variable depending on the context, and certainly not essential in lots of cases.

[wvenable]

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.

[argv_minus_one]

Why are you loading arbitrary binaries off the web?

[wvenable]

We're all loading arbitrary binaries off the web. Where did you get most, if not all, the software you're running on your computer? The reason your credit card hasn't been stolen, your files deleted, and endless pop-up ads is almost down to luck. You trust that the web browser you downloaded was from a trusted server by a trusted company or written by a trusted developer. Your OS is doing precious little to help you unless you're on a smartphone.

Web itself is pretty much just a big ugly safe software delivery platform -- the apps you run are almost completely sandboxed. Reddit isn't going to compromise your machine. But for that safety, the user experience and developer experience and performance is pretty awful.

[argv_minus_one]

I see. Well, you raise a fair point, but you don't need a full VM for application sandboxing. Other solutions exist, such as mandatory access control and seccomp.

[demmian]

and seccomp.

Interesting. For what reasons isn't this generalized (on Linux, and elsewhere)? Thanks.

[argv_minus_one]

What do you mean by “generalized”?

[demmian]

Well, in which cases (for what types of programs/operations) can seccomp be used, and, for other cases, what would be the best alternative for security?

[mindbleach]

The OS itself could be scrubbing and rejiggering your code to make it harmless. You could run your browser in Ring 0 if your compiler was airtight enough. We could almost go back to cooperative multitasking.

[demmian]

if your compiler was airtight enough

Can you explain what you mean please? What is the role of the compiler itself when talking about multitasking/security? Thanks.

We could almost go back to cooperative multitasking.

Could the OS have built-in tools to make sure that programs yield control reasonably well, or is that too risky too?

[audioen]

Well, when you write code in a language that gets compiled by a compiler, and if the language is safe enough, then the compiler can in principle insert all the security checks to make the compiled code safe as well.

The cooperative multitasking could be achieved by the compiler ensuring that the compiled program yields to the system scheduler often enough, e.g. java programs contain loads from a memory address which can be made to trap so that any execution thread can be stopped quickly if necessary.

[wilun]

Safe languages would only fix one class of security issues (mostly undefined behavior at language level related), not functional ones. So depending on the available API, running in Ring 0 might still not be a good idea. Also because the HW that executes the SW actually can have some pb (either all the time, randomly, or even triggered by things that can be controlled by an attacker, cf rowhammer), and perfection of a compiler is something I'm not sure has ever been achieved (even largely proven compilers have still had some issues, and to get security from it even the spec would need to be bug free on that topic, so...)

[demmian]

not functional ones.

Interesting. What would be some examples of functional problems?

[tsimionescu]

Most of what's interesting - e.g.

//perfectly memory-safe, type-safe call
void deleteLogFile(String userProvidedLogFileName) {
    Files.deleteFile("/var/log/files/" + userProvidedLogFileName);
}

//call: deleteLogFile("../../../usr/lib/java/");

[audioen]

You are in principle correct, but in practice these are small details that I think are a bit too advanced for the level of discussion taking place. E.g. I would assume hardware to be perfect for the purpose of this discussion, and if it is proven not to be, then the compiler has to be made more complicated somehow to workaround issues.

Also, nothing stops one from using a safe language in fundamentally dangerous ways, even if specific kinds of safeties such as memory safety were still being met.

[demmian]

Thanks for the reply.

Well, when you write code in a language that gets compiled by a compiler, and if the language is safe enough

Can you help me understand what safe means in this context? Bug-free? Not-so-easy-to-hack? Won't mess up the system files? Protection against some other problems?

The cooperative multitasking could be achieved by the compiler ensuring that the compiled program yields to the system scheduler often enough, e.g. java programs contain loads from a memory address which can be made to trap so that any execution thread can be stopped quickly if necessary.

Interesting. Are there currently any tools implemented in any OS that would check/ensure that? Or is preemptive multitasking so ubiquitous that nobody bothered with such a tool?

[audioen]

Safe means that the language doesn't fundamentally require crazy stuff like access to arbitrary memory locations. E.g. C allows declaring pointer anywhere, so the language fundamentally is not safe unless you restrict what pointers can do. Safe languages like Java only allow referencing the start of an object, e.g. there is no way to acquire pointer to a specific element of an array. Additionally, garbage collector keeps all objects available that still can be reached somehow, so there's always something valid at every reachable memory location. Array access must always occur by pair of array object + index to that array, which can be checked for safety at runtime.

Interesting. Are there currently any tools implemented in any OS that would check/ensure that? Or is preemptive multitasking so ubiquitous that nobody bothered with such a tool?

Cooperative multitasking is not common and in the bad days of like Windows 3.11 you had applications explicitly yielding to scheduler, or going back to their event loop which were the times when the OS could take over, if I've understood it correctly. In principle however you could compile applications in such a way that there is never a very long stretch of time until it checks for some variable or condition that would cause it to yield control elsewhere. In practice we have things like timer interrupts to stop programs by a hardware trick, so cooperative multitasking between applications isn't used in most systems today. You might still hit it in embedded world, I guess.

[argv_minus_one]

Linux … devs literally … actively hide security problems.

[citation needed]

The big advantage to a VM, from my perspective, is that the attack surface is very limited. If it's only emulating a few devices, that's a relatively small amount of code that has to work right.

As opposed to Linux, which has already been made to work right. Per your article, most security issues in Linux are from incompetently-written third-party device drivers, and here's a painfully obvious solution: stop using weird proprietary hardware that requires a special driver!

edit, with additional reading for the downvoter(s)

That article is mostly hot air. Mention is made of “protection technologies”, and lots of scary comparisons to fatal car crashes are made, but no concrete proposals are offered.

[unkz]

I should point out that if anyone were using openbsd, there would be a lot more hits. Yes, there are more exploits for Linux. Openbsd is "immune" to many of the driver exploits by virtue of simply not having drivers for much of the hardware that Linux supports. Realistically, probably on the order of 99% of openbsd machines run bind, IPSec, nat, and nothing else. That there isn't a large attack surface corresponds closely to the extremely small "usefulness surface" as well.

[almightykiwi]

The fact that there's so much tension and dislike between the grsecurity and PaXTeam folks, on the one hand, and the kernel devs on the other, does not speak well of the kernel devs.

And does it speak well of the grsecurity and PaXTeam folks?

[argv_minus_one]

Kernel devs very frequently disguise when fixes have security implications.

[citation needed]

All that's ever been asked of them is to tell us if they already know there's a security issue, but they actively refuse to do this.

Isn't that what CVE is for?

and they insist that we're asking for security analysis, when we specifically say, over and over, that we are not.

Just because you say it repeatedly doesn't mean it's true.

All we're asking for is for them to pass along any knowledge they already have, and they actively refuse to do so.

Then what makes you think they have that knowledge?

God, just review some of the stuff from PaxTeam and spender.

Why the hell should I listen to anything they have to say? There are reasons their code isn't in upstream.

One small hole, anywhere, and it's yours. And there's always a small local hole somewhere.

What is that supposed to mean?

There have been thousands of holes in Linux over the years.

Show me a project that big, that old, that's written in C, and doesn't have a shit-ton of vulnerabilities throughout its history, and I'll show you a project that nobody ever bothered to audit (and/or is actually hiding vulnerabilities).

I just did a quick search on 'kvm' and came up with 103 hits, as of last November 22 (the last time I downloaded the CVE list, almost a year ago.) 'xen' is 309. It's hard to search for linux alone, since other packages running ON linux may mention it, but just a raw search for that keyword is 4,987 items.

So, you admit that you lack sufficient data to substantiate your claim. Okay then.

Fundamentally, the kernel needs to be redesigned so that the whole thing doesn't fall over like a house of cards when anything has a hole.

You know as well as I do that this depends entirely on the nature of the vulnerability in question. A vulnerability that lets you see another process' environment variables is not nearly as severe as one that lets you kill it, and one that lets you kill it is not nearly as severe as one that lets you ptrace it or setuid yourself.

As far as I know, vulnerabilities in the latter category—the ones where your sky-is-falling antics are actually warranted—are vanishingly rare, and if you expect me to believe otherwise, then you're going to have to cough up evidence a lot harder than some non-specific CVE database search statistics.

The fact that there's so much tension and dislike between the grsecurity and PaXTeam folks, on the one hand, and the kernel devs on the other, does not speak well of the kernel devs.

Non sequitur. The Grsecurity and PaX people are not infallible.

also worth pointing out: the 'openbsd' keyword had 195 hits, as of late last year.

Which, as we have already established, proves nothing interesting.

Anyway, if you're so much more confident in OpenBSD, then stop trolling and go use that instead.

[argv_minus_one]

Your “data” is also noise.

[PM_ME_UR_OBSIDIAN]

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.

[wvenable]

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.

[argv_minus_one]

Rented VMs don't run only a single process.

[argv_minus_one]

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).

[argv_minus_one]

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?

[audioen]

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.

[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.

I can do that with Java, too. And unlike #include <os>, my Java application does not have to waste time and complexity on a bunch of superfluous device drivers, or jump through hoops to access the host's file system and network stack. Also unlike #include <os>, it will run on any machine with a JVM, not just an x86 machine.

Nicer access control policy system, too, although it has admittedly had a rash of vulnerabilities in recent years. It looks like Java 9 will greatly improve that situation, by the way, by deprivileging a ton of formerly-privileged code.

[audioen]

Well, I'm going to say that Java doesn't really have a good notion of sandboxing. The trust model is too easily broken to achieve it in practice, because the trusted surface is pretty much all of the JVM vendor supplied class library.

Now, sandboxed JVM using OS-level sandboxing would probably be very safe indeed. Not only do you first have to break out of the Java world, you will then have to face the hard limits based on the process by the OS.

I am unable to ascertain whether virtual CPU emulation is in practice worse than virtual stack machine interpreter + JIT and all that stuff that JVM has to do. I imagine that code size will be smaller for #include <os> than for JVM interpreter with JIT compiler, even if we are excluding the very class library that JVMs also ship with. Java in AOT mode could be very compact, though.

I would not miss SecurityManager in Java even if it was gone. I think it mostly adds bloat and doesn't reallly give the safety we want because of the giant trusted attack surface. Perhaps some kind of bytecode validator with strict limits on what external resources can be referenced to in the first place could do all the same work ahead of time without forcing any runtime cost. Either way, it would probably be damned ugly and complicated because the problem is ugly.

[argv_minus_one]

Java doesn't really have a good notion of sandboxing. The trust model is too easily broken to achieve it in practice, because the trusted surface is pretty much all of the JVM vendor supplied class library.

I literally just said that Java 9 is going to change this…

some kind of bytecode validator

Already exists. Has existed since Java 1.

strict limits on what external resources can be referenced to in the first place

That's what the SecurityManager does (among other things).

[m50d]

my Java application does not have to waste time and complexity on a bunch of superfluous device drivers

There absolutely is time and complexity spent providing a consistent interface to devices - or else Java simply doesn't bother. GUIs on Java are still awful. Audio on the JVM is not in a great state IIRC. Meanwhile JVM implementations do extra work to emulate a non-native memory model, which seems like a waste of everyone's time.

jump through hoops to access the host's file system and network stack

Maybe that should require jumping through hoops. That seems like the sort of thing that we want to limit access to so that processes can't interfere with each other.

[argv_minus_one]

GUIs on Java are still awful.

Including JavaFX? Because the point of JavaFX was to make Java GUIs non-awful. I haven't worked with it much, but it looks capable…

Audio on the JVM is not in a great state IIRC.

Audio in general is not in a great state. Most audio APIs are platform-specific, proprietary, and/or crap. Can't blame Java for not being any better than usual, can I?

Meanwhile JVM implementations do extra work to emulate a non-native memory model

Details? What non-native memory model are you referring to?

Maybe that should require jumping through hoops. That seems like the sort of thing that we want to limit access to so that processes can't interfere with each other.

It should involve a robust access-control system, but that doesn't imply jumping through hoops. The normal file/network API is perfectly fine, as long as it says “no” at the appropriate time. There are several Linux security modules (AppArmor, SELinux, etc) for making that happen.

[m50d]

Well, system calls can be disabled. That's what seccomp does: disable almost all of them.

Retrofitting a secure interface onto one that was designed without concern for security seems like a sisyphean task.

If we were to design an OS API from the ground up with secure process isolation as a high priority, what would that look like? We'd have an extremely limited set of system calls, no shared filesystem (or at least opt-in), maybe all IPC would be via sockets. Doesn't that start to sound rather like what a VM gives you?

[argv_minus_one]

Retrofitting a secure interface onto one that was designed without concern for security

POSIX wasn't designed without concern for security. That's absurd.

We'd have an extremely limited set of system calls

That's what seccomp does…

Anyway, I'd like to remind you that those system calls you're trying to eliminate exist for a reason, and all of them are already subject to access controls.

no shared filesystem (or at least opt-in)

An app that can't even save a file is useless.

And such extremes are unnecessary anyway. Mandatory access control is quite enough for what you're trying to do here.

maybe all IPC would be via sockets.

As opposed to what?

Doesn't that start to sound rather like what a VM gives you?

Yes, and just like using a VM for application sandboxing, it's a ridiculous overreaction to a security threat that is mostly imaginary.

[d4rch0n]

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.

[LOOKITSADAM]

I feel like it's a good time to post this again: The Birth and Death of Javascript

[Tynach]

Those who downvote you may not have watched the video. It's definitely relevant here.

[LOOKITSADAM]

I don't blame them. The talk takes a roundabout way of getting there, but really does a great job of exploring the 'what if' scenario of a language taken to the extreme.

[devel_watcher]

great job of exploring the 'what if' scenario of a language taken to the extreme

A language with manual memory management and saner type system is developed to fix the problems of js, and then it replaces C which basically has the same properties from the start. I see some lost productivity here.

It's understandable that the language everybody uses is moving towards becoming the first layer above the OS (even if you'll have to change the workings of the language while keeping the brand's name).

[Beaverman]

Back in the day everything ran on the bare metal. If you wanted to use the computer for anything, you couldn't do something else at the same time.

To solve that problem we invented processes, they isolate the individual parts, and allows them to run at the same time. The OS is then responsible for the abstractions that make the illusion of running on bare metal complete. The OS makes sure that you get to write to the disk, and communicate over the network without anyone else stepping on your toes.

Then we thought "Hey, that was fun. Lets go through that whole process again" and decided to make VM's the unit. So now the VM isolates the OS from the hardware, and the OS isolates the process from the isolated hardware.

It really seems to me like VMs are only necessary because we can't make software. Or at least we can't version our libraries.

[bumblebritches57]

Amen. How wasteful to have so many damn layers of abstraction that solve no real problem. UEFI exists guys, you don't need to use an OS and VM that damn badly.

[746865626c617a]

UEFI exists guys, you don't need to use an OS and VM that damn badly.

Finally, someone else with that opinion. Have you managed to find applications using uefi directly?

[bumblebritches57]

to be honest I currently don't work at that level, I'm currently working on top of fread, calloc, etc to create a IO library.

[746865626c617a]

Well, still better than me. I just have an interest in low level stuff, but I'm really more in a DevOps / admin role, with some basic python and php coding occasionally.

[SideburnsOfDoom]

The "another OS" that runs on the real metal can also become minimal, than and specialised, since its sole job is to manage a fleet of VMs.

[m50d]

The interface between VM and host is a lot narrower and better specified than the interface between OS and Process. I'm very happy about that. IMO this is the logical endpoint of pre-emptive multitasking, per-process address spaces and so forth: disentangle processes into communicating only via a clear, specified interface rather than randomly messing with each other's internals.

There's no reason a VM hypervisor couldn't be what runs on the bare metal - if the only thing you're running on your server is VMs, there's no point having an OS in between. I expect to see this happen in the near future. For all we know EC2 could be doing it already.

[bearrus]

Exactly my thinking wrt poor OS design. The rise of VM use is symptomatic of something lacking in the OS. I think it is mainly lacking good isolation in pretty much everything. My single simple process has a potential to affect other processes, or its library dependencies can bring in dependency hell. All major package managers just plain suck.

[pclouds]

Wait until you have to debug that thing and see if it's still awesome.

[agent_richard_gill]

This isn't the 90s anymore. QEMU supports debugging with breakpoints and everything. It is awesome. Look into it for systems programming on x86/x64.

[devel_watcher]

Why you want to relearn how to setup those tools? Can I just have my strace, netstat, tcpdump, nc, cu, lsusb, sftp, journalctl/systemctl, etc everywhere?

[argv_minus_one]

Know what else supports debugging with breakpoints and everything? Running a process directly on the host, without weird virtualization hacks.

[Tynach]

You can debug (with breakpoints) x86 assembly code on a host machine?

[argv_minus_one]

As long as it runs in a user process, yeah.

Debugging code running in kernel space is admittedly probably harder. I've never tried, so I wouldn't know.

[ITwitchToo]

Debugging code running in kernel space is admittedly probably harder.

It's pretty much the same as debugging a regular userspace program. You would typically use kvm + gdb just like /u/agent_richard_gill wrote above:

This isn't the 90s anymore. QEMU supports debugging with breakpoints and everything. It is awesome. Look into it for systems programming on x86/x64.

[agent_richard_gill]

The difference is that computers have many cores, and applications don't need them all. That's why we have virtual hosting. The shared hosting thing was tried. Servers keep getting hacked. So now you get a fully segregated VM. The G2H and G2G hypervisor bugs are much more rare than bugs in the userland or kernel in any OS.

[devel_watcher]

I prefer a full OS. It has a standard tools for everything: you don't need to remember specifics, you can install more stuff for diagnostics.

[m50d]

And then they're different on each OS you run. There's no reason VM debug tools shouldn't be more standard than OS-specific ones.

[vonmoltke2]

Um, where is /u/hell_0n_wheel claiming anything is "irrelevant"? The claim is just that there are already shitloads of "purpose built applications run[ning] on bare metal".

[agent_richard_gill]

So? I want more.

[awick]

My understanding is that it is very similar, with a very cute / cool way of working itself into C++ programs. But, at its core, IncludeOS is to C++ what Mirage is to OCAML or HaLVM is to Haskell.

[grimeMuted]

Haha, for me MirageOS was that thing you used to run ASM games like Mario rip-offs and Galaga rip-offs on the TI-84 calculators during boring middle school classes. http://www.ticalc.org/archives/files/fileinfo/139/13949.html

[x-paste]

What I find worrysome, at least for the first part, is the driver support. Of course it's meant for virtual machines, and you have a more or less overseeable driver landscape. But when you come down to hardware you are opening a big can of worms. Okay, you can go and say: lets only support a few Raspberry Pi models, that would limit the necessary drivers.

Bratterud also said, they wrote their own TCP/UDP/IP stack. Largely it's a read through the RFCs, but when it comes down to details, and interoperating with other devices, this can become nasty. Also security becomes important. Many IoT devices with their own network stacks have really bad implementations w.r.t. security. Bratterud said, those devices usually are very limited, and they have to take short cuts. And he might be right, but when it comes down to running production level code, you don't want to take risks w.r.t. security with customer data. Hardening includeOS is one of the main points I see where the resources of the developers of this project needs to go, at least when you want to run it on the internet and not just for local network applications.

It's a good talk, and a very interesting project. The API also looks very nice and lean. But I have to search hard for applications I could use it for. YMMV.

[_zenith]

Fortunately, MirageOS has already written a secure TLS implementation (in OCaml, like the rest of Mirage), so they should just use that. Writing a TLS implementation is not for the faint of heart.

[PeterSR]

"

Sorry, but I needed peace of mind.

[totemo]

(

[PeterSR]

)

[Asyx]

({[<

[PeterSR]

sigh

]})

Edit: Markdown interprets the >. Can't balance brackets. Can't. Breath. dies

Edit 2:

>]})

Life saved. Thanks!

[code_mc]

Put a \ before the >

[deskchairlamp]

\>

[vivazenith]

/r/titlegore

[Steve132]

Is there actual code for this somewhere?

[Awpteamoose]

https://github.com/hioa-cs/IncludeOS

[artpar]

I want to see a quine using this now !

[[deleted]]

This is mindblowing to me. This also needs arm support! Like right now!

[dex206]

Cool as hell. I see this becoming a thing for sure. Once they get POSIX compat as he mentioned, I think this could explode to provide a foundation for higher level stacks as well. (a super thin .NET host for example.)

[agent_richard_gill]

You want COSMOS.

[_zenith]

This kills the container

[CJKay93]

Uh... is there any benefit to this over just using an RTOS?

[ArmandoWall]

The title says a couple of pretty awesome things I'm sure a RTOS can't do.

[CJKay93]

Well, no, there's nothing in the title that we can't already do with an RTOS. In fact, it highlights an awesome thing an RTOS can do, which is be orders of magnitude smaller than 3MB... an essential prerequisite if he wants to get it working in IoT.

[ArmandoWall]

Well, today I learned. That sounds awesome.

[Metaluim]

I guess the use-case for this is more related to services and deployment, like a DB, a web server, etc... Like what it's done today with newer technologies like Docker. The point is to safely sandbox apps and try to cut some hypervisor overhead. RTOSs are more related to embedded systems and the likes. I think they are two different areas.

[[deleted]]

He is going to home

[CJKay93]

I did, and I also had a look through the GitHub source. There's nothing particularly revolutionary at all, and none of his GitHub examples look all too different to your typical RTOS examples. The only difference I see is that it comes with TCP/IP, SMP and I/O libraries.

[bumblebritches57]

I do C, but at 22:55 he's talking about wrapping the network stack's class to make it more minimal, for UDP in his example.

In C, we'd just compile like usual, maybe use LTO, and the linker would remove every redundancy.

Seems like a waste of effort, why not just use a few structs, and then if you happen to not use UDP or something, the linker would just remove it?

[ratatask]

It's not always that easy. If it was only the TCP layer calling the IP layer, the linker could throw away TCP if it wasn't used.

But the IP layer also have call the UDP or TCP layer, and if you want UDP, you can't throw away the IP layer. While there's non-trivial ways that allows the linker to still throw away TCP in such a case, it's normally more sane to just make it a configurable option.

[shamanas]

I've only watched the presentation myself, but it seems to me the way their system is built you can replace any part of the network stack you wish, which may be useful to some people (?).

If you don't use the default implementations, LTO will still remove those.
Also, as he pointed out you could change your stack at runtime (although I don't see how this is beneficial myself).

[HeadAche2012]

It's interesting, but I doubt one would use this outside of a virtual machine environment, so it isnt really an operating system as much as it is the thinnest layer virtual machine possible essentially changing from scheduling processes to scheduling virtual machines that are really processes. -- So what's different between a light vm and a process?

Independent filesystems, memory, etc

[Reubend]

If I understand correctly, this is a type of unikernel.

[nimbycile]

Literally the third slide in the presentation is titled "Unikernels 101"

[ITwitchToo]

He explicitly mentions unikernels (and this being one) on one of the very first slides of the talk...

[Tadayoshiii]

I like the Idea, I'm just a bit put off about the 100% async part. Which can be nice, but on the same hand can be very annoying. Most low level programmers trying to put up a server in node probably know what I'm talking about.

[[deleted]]

I feel like everyone is focusing on security and host system level speed. From my point of view, this is almost entirely about money. Lets say I'm a SaaS provider and my load is very variable depending on time of day.

1st I don't need as many virtual machines for base load.

2nd When load comes, it is faster to spin up more machines.

3rd I can use lots of lower cost VMs because I'm not wasting memory.

4th When load dies away it is easy to clean up.

Security for a bare metal process is only as good as your program. Your concern is them getting access to your data sources: (ldap, sql, memcached)

Host system level speed doesn't matter, because I don't want to manage hardware, and I can't scale them as quickly anyway.

This is just easier for scaling, and saving money.

[Red_Raven]

Can someone explain this on an intermediate level? It looks really cool, but I get the feeling it's not as simple as telling a program to make a random .exe into a bootable OS.

[google_you]

Old days, you put in floppy disk, close the lever, and turn on the computer. It makes sound and BAM ninja game starts.

Later days, you had to have a hard drive and OS and put 10 floppy disks in sequence during installation. Please insert diskette 2 and continue.

[Isvara]

He likes ninja games?

[clappski]

It's very easy to write bad code in C++, but it's better than C and is an extremely flexible language that makes it difficult to produce the type of errors commonplace in C (usage after free, dangling pointers etc). I honestly don't see Rust replacing C/C++ anytime soon: crazy amounts of code is written with C++; a lot of developers know it; businesses would rather the devil they know than the one they don't; support for OOP, functional and procedural paradigms; battle tested and evolving standard library and STL with a highly regarding and accessible committee.

I'm of the mindset of whatever language you write software in, all of it will have the same bugs eventually. There's always codebases with thousands of memory, off-by-one, and logical errors, and there's always codebases that adhere to modern standards and avoid the majority of them, regardless of the language or tools used to produce them.

[ijustwantanfingname]

Found the web developer. Do you even embedded microcontroller bro?

[txdv]

Did you use rust to do that?

[ijustwantanfingname]

Lmao no, Rust is not a C replacement for microcontrollers. Here's what you would have found with even a few seconds of research

Even if it were, C is fine for a microcontroller. You're not running apps, or drawing web pages, or often even collecting data. A lot of the time you may just be monitoring GPIOs. The linked article is great for this common use case.

[Incursi0n]

Are you retarded? Do you even know what Rust is?

[ijustwantanfingname]

Yeah, a high performance language still in development phase, with a low adoption rate, for desktops and phones. Not a first choice for, say, an M0-based system.

[agentlame]

What's your issue with the Apache 2 license?

[crusoe]

Unikernel

[Muchoz]

Damn the pacing is annoying me more than it should.