A Tale of Two Kernels: Towards Ending Kernel Hardening Wars with Split Kernel [pdf]
1–10 of 14 posts
Re: A Tale of Two Kernels: Towards Ending Kernel Hardening Wars with Split Kernel [pdf]
#2All 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.
Re: A Tale of Two Kernels: Towards Ending Kernel Hardening Wars with Split Kernel [pdf]
#3All 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…
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.
Re: A Tale of Two Kernels: Towards Ending Kernel Hardening Wars with Split Kernel [pdf]
#4All 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…
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 o…
It's starting to happen. All we need is a non-C OS that can run Docker containers.
Re: A Tale of Two Kernels: Towards Ending Kernel Hardening Wars with Split Kernel [pdf]
#5Earlier quoted context omitted.
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 o…
It's starting to happen. All we need is a non-C OS that can run Docker containers.
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."
Re: A Tale of Two Kernels: Towards Ending Kernel Hardening Wars with Split Kernel [pdf]
#6All 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…
Need to have C replacement for embedded too. Something with C code density and ability to run with just kilobytes of code and RAM.
Maybe Rust can be that language one day.
Re: A Tale of Two Kernels: Towards Ending Kernel Hardening Wars with Split Kernel [pdf]
#7All 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…
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 o…
> 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.
Rust has the same control over memory layout.
And Cyclone used a GC; it wasn't as minimal as you think. The stuff needed to actually get rid of a GC while maintaining memory safety (retaining dynamic memory allocation) didn't really get developed in a practical way (IMHO, anyway) until Rust came along.
Re: A Tale of Two Kernels: Towards Ending Kernel Hardening Wars with Split Kernel [pdf]
#8Earlier quoted context omitted.
It's starting to happen. All we need is a non-C OS that can run Docker containers.
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…
What about Linux-Branded Zones? They let you natively execute Linux binaries on any IllumOS-based operating system. Zones themselves have a proven security record that easily make up for the lack of real security in the container space.
That isn't to say that IllumOS and Zones are perfect, but if something that robust can be implemented in C/C++, we can do the same or better in Rust.
Re: A Tale of Two Kernels: Towards Ending Kernel Hardening Wars with Split Kernel [pdf]
#9Earlier quoted context omitted.
It's starting to happen. All we need is a non-C OS that can run Docker containers.
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 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.
Re: A Tale of Two Kernels: Towards Ending Kernel Hardening Wars with Split Kernel [pdf]
#10Earlier quoted context omitted.
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 o…
It's starting to happen. All we need is a non-C OS that can run Docker containers.
It's happened before: Ada Secure Operating System, LISP machines, Pascal machines, BiiN, System/38, Oberon System, and so on. It's why I love online comments speculating about whether it's possible to use a type-safe or memory-safe language to write a full OS. Lol. I try to remind them of what's been done before enough so hopefully they'll try to do it again.
I agree a modern take supporting mainstream deployment tech would be a great advance. The language itself might need to be modern. They'll reject Ada, LISP, etc. I liked JX just because there were many Java developers plus various verification tech on Java subsets. Figured Java-2-native was only shot before Rust, Go, and SWIFT showed up. Things are indeed starting to happen. :)