5 ms·

Looks like you are quoting from: http://arstechnica.com/security/2016/09/linux-kernel-security-needs-fixing/ http://arstechnica.com/security/2016/09/linux-kerne

by kentonv 10y ago

Looks like you are quoting from: http://arstechnica.com/security/2016/09/linux-kernel-security-needs-fixing/ http://arstechnica.com/security/2016/09/linux-kernel-securit... While it's true that vendor drivers living in kernel space is horrible for security... that's somewhat offtopic here. This particular bug is in the memory management system, which is one of those things that kind of has to be in the kernel. A microkernel architecture seemingly would not have helped in this particular case.

wbl 10y ago
seL4 does not have these kinds of errors. By shrinking the TCB, you make it possible to do hardcore verification. The challenge is in extending to larger systems and composition.
- snvzz 10y ago
  Worth noting that as of Genode's latest release, a lot of progress has been made in that regard.
drieddust 10y ago
Yeah not sure what happened. Somehow I ended up looking at wrong article. I am not very good at theory of Operating Systems but since Memory Management is separated from kernel it would have been difficult for a memory bug to impact other subsystems. Another argument is modularity which would have allowed better testing hence lesser chances of bugs.
- sheer_horror 10y ago
  Despite your erroneous reply, you still hit 4th most upvoted comment thanks to the pro-open source sentiment here.
  - drieddust 10y ago
    Yep but my argument still holds true especially in the era of IoT risks are now becoming physical. Bugs earlier used to only impact people financially, emotionally but now risks are physical.
  - snvzz 10y ago
    Why do you think it is erroneous?
snvzz 10y ago
> This particular bug is in the memory management system, which is one of those things that kind of has to be in the kernel. Not really. L4 family (the post-Liedtke world) and Minix3 both have MM out of the kernel.
- AstralStorm 10y ago
  A privilege escalation in MM daemon would still allow you to write and read any user memory. Just not kernel memory or execute anything not covered by memory access capabilities. For nearly all intents and purposes, it is root.
  - snvzz 10y ago
    Couple things here. Firstly, as the MM daemon runs on its own process and is well-separated from other code, it is far easier to audit, debug and so on. Its interface is also entirely explicit. There's value in modular programming. It's far more reasonable to expect quality from such a MM daemon than the mess in a random monolith kernel. Secondly, in seL4, physical pages are capabilities. There might be more than one MM daemon, owning separate sets of capabilities to physical pages. Security-critical memory might be managed by a MM daemon your vulnerable process has no capability to talk to. Just my two cents.

by kentonv 10y ago

wbl 10y ago

seL4 does not have these kinds of errors. By shrinking the TCB, you make it possible to do hardcore verification. The challenge is in extending to larger systems and composition.

snvzz 10y ago
Worth noting that as of Genode's latest release, a lot of progress has been made in that regard.

drieddust 10y ago

Yeah not sure what happened. Somehow I ended up looking at wrong article. I am not very good at theory of Operating Systems but since Memory Management is separated from kernel it would have been difficult for a memory bug to impact other subsystems. Another argument is modularity which would have allowed better testing hence lesser chances of bugs.

sheer_horror 10y ago
Despite your erroneous reply, you still hit 4th most upvoted comment thanks to the pro-open source sentiment here.
- drieddust 10y ago
  Yep but my argument still holds true especially in the era of IoT risks are now becoming physical. Bugs earlier used to only impact people financially, emotionally but now risks are physical.
- snvzz 10y ago
  Why do you think it is erroneous?

snvzz 10y ago

> This particular bug is in the memory management system, which is one of those things that kind of has to be in the kernel. Not really. L4 family (the post-Liedtke world) and Minix3 both have MM out of the kernel.

AstralStorm 10y ago
A privilege escalation in MM daemon would still allow you to write and read any user memory. Just not kernel memory or execute anything not covered by memory access capabilities. For nearly all intents and purposes, it is root.
- snvzz 10y ago
  Couple things here. Firstly, as the MM daemon runs on its own process and is well-separated from other code, it is far easier to audit, debug and so on. Its interface is also entirely explicit. There's value in modular programming. It's far more reasonable to expect quality from such a MM daemon than the mess in a random monolith kernel. Secondly, in seL4, physical pages are capabilities. There might be more than one MM daemon, owning separate sets of capabilities to physical pages. Security-critical memory might be managed by a MM daemon your vulnerable process has no capability to talk to. Just my two cents.