Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linux kernel use-after-free in Netfilter, local privilege escalation

seclists.org

Post reply on HN
Print view View original

101–107 of 107 posts

Re: Linux kernel use-after-free in Netfilter, local privilege escalation

#101

Post by aflag »

pjmlp wrote: post #94
aflag wrote: post #84

Earlier quoted context omitted.

Hm, if you're making the underlying hardware slower, don't you want the kernel to be even faster though? VMs are much more than micro kernels. It's about allowing the user to install whatever they want in their machine. Containers are just a userland abstraction. Not sure where the link to microkernels is there.

Not when using hypervisor type 1.

Why not? Hypervisor type 1 has less overhead, but it's still not quite the same as running directly on the box. I don't think micro kernels would replace those anyway. To be honest, I don't even really see the connection between running most of the kernel in user space and allowing concurrent systems to run in the same hardware.

Re: Linux kernel use-after-free in Netfilter, local privilege escalation

#102

Post by saagarjha »

snvzz wrote: post #74
saagarjha wrote: post #65

Earlier quoted context omitted.

I'm not really in the mood for trolling.

The name-calling is uncalled for. To elaborate, seL4 claims to be the fastest kernel around[0], a claim that remains unchallenged. To put it into context, the difference in IPC speed is such that you'd need an order of magnitude more IPC for a multiserver system based on seL4 to actually be slower than Linux. A multiserver design would imply increased IPC use, but not an order of magnitude. 0. https://trustworthy.sys…

No, it doesn’t. Here’s the full quote from their website:

> seL4 is the world’s fastest operating system kernel designed for security and safety

Linux is arguably not designed for security and safety but it blows seL4 out of the water when it comes to performance. There’s a reason it only gets used in contexts where security is critical; I would have expected that you would be aware of this considering you were the one who is promoting it.

Re: Linux kernel use-after-free in Netfilter, local privilege escalation

#103

Post by snvzz »

saagarjha wrote: post #102
snvzz wrote: post #74

Earlier quoted context omitted.

The name-calling is uncalled for. To elaborate, seL4 claims to be the fastest kernel around[0], a claim that remains unchallenged. To put it into context, the difference in IPC speed is such that you'd need an order of magnitude more IPC for a multiserver system based on seL4 to actually be slower than Linux. A multiserver design would imply increased IPC use, but not an order of magnitude. 0. https://trustworthy.sys…

No, it doesn’t. Here’s the full quote from their website: > seL4 is the world’s fastest operating system kernel designed for security and safety Linux is arguably not designed for security and safety but it blows seL4 out of the water when it comes to performance. There’s a reason it only gets used in contexts where security is critical; I would have expected that you would be aware of this considering you were the o…

>but it blows seL4 out of the water when it comes to performance.

Citation needed.

And by that I mean actual benchmarks of Linux doing the few tasks seL4 does, such as IPC or context switching, faster than seL4.

Re: Linux kernel use-after-free in Netfilter, local privilege escalation

#104

Post by saagarjha »

snvzz wrote: post #103
saagarjha wrote: post #102

Earlier quoted context omitted.

No, it doesn’t. Here’s the full quote from their website: > seL4 is the world’s fastest operating system kernel designed for security and safety Linux is arguably not designed for security and safety but it blows seL4 out of the water when it comes to performance. There’s a reason it only gets used in contexts where security is critical; I would have expected that you would be aware of this considering you were the o…

>but it blows seL4 out of the water when it comes to performance. Citation needed. And by that I mean actual benchmarks of Linux doing the few tasks seL4 does, such as IPC or context switching, faster than seL4.

No, you don’t get to define the benchmarks like that. People use an OS so they can run real-world programs on top of it, not spin it in a loop and see how fast it can do IPC. In a monolithic kernel there’s no need to switch contexts for many things; that’s the entire point of using one. I’m sure that seL4 has a perfectly fast implementation of those operations but that’s because it sits and does those all day as part of its basic functionality. Optimizing overhead doesn’t win you extra points when you’re comparing against an OS that doesn’t have it all.

Re: Linux kernel use-after-free in Netfilter, local privilege escalation

#105

Post by snvzz »

aflag wrote: post #101
pjmlp wrote: post #94

Earlier quoted context omitted.

Not when using hypervisor type 1.

Why not? Hypervisor type 1 has less overhead, but it's still not quite the same as running directly on the box. I don't think micro kernels would replace those anyway. To be honest, I don't even really see the connection between running most of the kernel in user space and allowing concurrent systems to run in the same hardware.

seL4 with its VMM is a better hypervisor architecture than, say, Xen.

Xen is unfortunately large, and the full hypervisor runs privileged.

With seL4, VM exceptions are forwarded to VMM, which handles them.

From a security standpoint, a VM escape would only yield VMM privileges, which are no higher than that of the VM itself. This is much better than a compromise of Xen, which would compromise all VMs in the system.

Makatea[0] is an effort to build a Qubes-like system using seL4 and its virtualization support. It is currently funded by a NLNet grant.

0. https://trustworthy.systems/projects/TS/makatea

Re: Linux kernel use-after-free in Netfilter, local privilege escalation

#106

Post by snvzz »

saagarjha wrote: post #104
snvzz wrote: post #103

Earlier quoted context omitted.

>but it blows seL4 out of the water when it comes to performance. Citation needed. And by that I mean actual benchmarks of Linux doing the few tasks seL4 does, such as IPC or context switching, faster than seL4.

No, you don’t get to define the benchmarks like that. People use an OS so they can run real-world programs on top of it, not spin it in a loop and see how fast it can do IPC. In a monolithic kernel there’s no need to switch contexts for many things; that’s the entire point of using one. I’m sure that seL4 has a perfectly fast implementation of those operations but that’s because it sits and does those all day as part…

seL4 is an order of magnitude faster at this "overhead" thing. We're talking nanoseconds vs microseconds difference.

The multiserver architecture does indeed imply an elevated use of IPC, but it does in no way outweigh the difference in IPC cost.

In this model, data sharing, and the implied locking, is minimized, which as a consequence helps SMP scaling.

Dragonfly, while not multiserver proper, took a different direction than Freebsd and Linux by optimizing IPC and not implementing fine-grained locks, and instead favoring concurrent lockless and lockfree servers.

As a consequence, Dragonfly scales much better than Freebsd, and in many benchmarks manages to outperform Linux.

This is despite the tiny development team, particularly so when considered relative to the amount of funding these two systems get.

I am sickened by the effort that's being wasted on a model that we know is bad and does not work. Linux will never be high assurance, secure or scale past a certain point.

Fortunately, no matter how long it'll take, the better technology will win; there's no "performance hack" that a bad system can pull to catch up with the better technology once it's there.

Just a matter of time.

Post reply on HN