
A Tale of Two Kernels: Towards Ending Kernel Hardening Wars with Split Kernel [pdf] - groupmonoid
https://web.archive.org/web/20150120160031/http://split.kernel.build/papers/ccs14.pdf
======
nickpsecurity
I think it's interesting work with performance tradeoff and such. I've even
used this same approach at the library level where some are optimized for
speed and some safety depending on app they're integrated with. Yet, there's
two things going against it for system protection: (a) OS's have so many
potential vulnerabilities and covert channels that it's best to isolate them
entirely into a protection domain with careful interfaces to other partitions;
(b) the protection schemes on code, hardware or software, have gotten _much_
better than the limited guarantees this scheme offers with performance hit
that we can live with. Regarding (b), they even referenced one (SVA-OS) I
considered building a medium-assurance design on. Softbound for full, C memory
safety is also interesting and Control Pointer Integrity if you have segments.

Many interesting tech for turning exploits into mere exceptions or things that
don't compile in the first place. Also many tech's for isolating all that mess
in a box with low overhead and easier-to-check interface protection. I'd
rather take a combination of those than a split kernel.

------
Animats
All this does is clear the stack area prior to each Linux kernel call and
check, at the instruction level, for stack pointer problems. That's nice, but
narrow. The approach is to do this at boot time, which is kind of strange and
may introduce more security errors.

It might be more useful to do this for all kernel calls other than the top 10.
Vulnerabilities are more likely to be present in less-used system calls, where
the code isn't exercised much. We know now that the "with many eyes, all bugs
are shallow" meme is bogus. Much code in open source software barely gets
looked at by anybody.

If this is useful, Linux kernel call code is very buggy.

This is, of course, a C problem. We've really got to get rid of C for anything
security-critical.

~~~
vezzy-fnord
_This is, of course, a C problem. We 've really got to get rid of C for
anything security-critical._

On the other hand, it must be noted that there's a ton of subtle timing-
related attacks in crypto where low-level control of memory layout strongly
benefits their mitigation [1]. I don't know how mechanisms provided by
languages like Rust fare into this, though C has definitely been tried and
tested well.

Then the idea of moving away GNU, the Linux kernel, Freedesktop projects and
all the other myriad software from C is a pipe dream, anyway. It _might_ have
been attainable if something like Cyclone won out which extended C only to a
minimum for security purposes, but otherwise the task is immense.

[1]
[https://cryptocoding.net/index.php/Coding_rules](https://cryptocoding.net/index.php/Coding_rules)

~~~
Animats
It's starting to happen. All we need is a non-C OS that can run Docker
containers.

~~~
vezzy-fnord
The expression "non-C OS that can run Docker containers" reeks of magical
thinking through and through, but for what it's worth the purpose of Docker is
application containerization, which is more concerned with logical resource
partitioning, infrastructure granularity and an escape from the broader state-
related issues of the shared library context in the host OS.

Sandboxing is orthogonal. It so happens that some of the techniques of OS-
level virtualization overlap with those of sandboxing on Linux, but Docker is
nonetheless not a security tool.

Not that Docker's current libcontainer work is even at all portable. It's
questionable what the current ruckus about companies backing the Open
Container Project will lead to.

I'll let Theo take it from here:

"You are absolutely deluded, if not stupid, if you think that a worldwide
collection of software engineers who can't write operating systems or
applications without security holes, can then turn around and suddenly write
virtualization layers without security holes."

~~~
nickpsecurity
There's been many highly-secure virtualization prototypes or production
systems that leveraged tiny kernels with minimally-complex trusted software.
Kernel-mode code for modern ones was around 10Kloc. On a virtualizable
architecture, this is way easier to do than a whole OS given the complexity of
the latter. Plus, it's best to entrust the best security engineers and
software engineers to build it with similar to certify it rather than "a
worldwide collection of software engineers" unqualified for the job.

Right people, right tools, right architecture, and right processes for
knocking out defects. That's what it takes. Virtualization's well-studied
enough to tackle it. Only one's trying in FOSS that I'm aware of are L4
community: esp TU Dresden Nizza architecture w/ L4 Linux, OK Labs OKL4/seL4 /
OK Linux, and GenodeOS on Nova microhypervisor or OKL4. Google separation
kernel, Nizza and Genode architectures to see what I mean.

~~~
vezzy-fnord
I'm aware of that. I was mostly responding to the specific notion of "non-C OS
running Docker containers", which is asinine.

The research OS space is mostly doomed to languish in obscurity, but it seems
like MirageOS just _might_ stand a chance.

~~~
nickpsecurity
I totally agree on MirageOS. Very exciting work applying good principles to
the container concept. Work that's gotten noticed and might get used
widespread one day. A situation so rare it's worth a toast to them! Lol.

