A Tale of Two Kernels: Towards Ending Kernel Hardening Wars with Split Kernel [pdf] • Hacker News Board

Re: A Tale of Two Kernels: Towards Ending Kernel Hardening Wars with Split Kernel [pdf]

#11

Post by nickpsecurity » Wed, Jun 24, 2015, 11:33 PM UTC

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.

Re: A Tale of Two Kernels: Towards Ending Kernel Hardening Wars with Split Kernel [pdf]

#12

Post by vezzy-fnord » Thu, Jun 25, 2015, 12:17 AM UTC

nickpsecurity wrote: post #9

vezzy-fnord wrote: post #5

Earlier quoted context omitted.

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…

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 cer…

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.

Re: A Tale of Two Kernels: Towards Ending Kernel Hardening Wars with Split Kernel [pdf]

#13

Post by nickpsecurity » Thu, Jun 25, 2015, 1:02 AM UTC

vezzy-fnord wrote: post #12

nickpsecurity wrote: post #9

Earlier quoted context omitted.

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 cer…

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.

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.

Re: A Tale of Two Kernels: Towards Ending Kernel Hardening Wars with Split Kernel [pdf]

#14

Post by kjs3 » Thu, Jun 25, 2015, 2:29 PM UTC

Animats wrote: post #2

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, wh…

Anyone who is really interested in a mature, industrial strength, system programming language without the fundamental flaws of C have been able to crank up an Ada compiler for years (including the free, GNU licensed GNAT compiler). And along the way there have been a lot of other solid options that have been used to build reliable systems (personally, I think Modula-3 should have gotten a lot more love than it did, especially since it had a free compiler as well...alas).

The reality is, there's a bunch of people who spend a lot of time furiously wanking over the NextCoolLanguage du jour, espousing how it's obviously going to displace C and cure all our ills, while the people who are actually writing things people use are by-and-large content to keep doing it in C. If the people that really matter in this debate wanted a better language than C, they'd have picked one a long time ago.