5 ms·

>However that's hard to do when the vast majority of kernel bugs come from vendor drivers, not the upstream Linux kernel, Stoep said. Doesn't this actually val

>However that's hard to do when the vast majority of kernel bugs come from vendor drivers, not the upstream Linux kernel, Stoep said. Doesn't this actually validate Andrew Tannenbaum's argument[1] over 25 years ago when he said monolithic operating systems are inherently insecure and a rethink is required. [1] https://groups.google.com/forum/m/?fromgroups#!topic/comp.os.minix/wlhw16QWltI https://groups.google.com/forum/m/?fromgroups#!topic/comp.os...

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.
pjmlp 10y ago
While it is in part true, no amount of band-aid solutions will fix the issue of using C.
- snvzz 10y ago
  A small TCB will still be key, regardless of language.
  - pjmlp 10y ago
    10% small TCB size vs 100% of the complete code. Which one will a security minded person pick?
    - snvzz 10y ago
      Sorry, can you restate that question? I'm not sure what you're asking.
      - pjmlp 10y ago
        A small TCB -> around 10% unsafe code. C, due to arrays, strings, arithmetic operations and memory allocations requiring unsafe code leads to 100% unsafe code across the existing code. A security minded person will pick those 10%.
        snvzz 10y ago
        > C, due to arrays, strings, arithmetic operations and memory allocations requiring unsafe code leads to 100% unsafe code across the existing code. Imply is just slightly too harsh. Writing safe C code is very possible, as proven by projects such as seL4 or engineers such as djb.
        pjmlp 10y ago
        Those projects had to constrained themselves to having 100% of the code available, no binary libraries and lock the compiler versions being used. Since the early 90's I keep hearing that it is possible to write safe C code, yet outside in the real world, unless constrained by processes like MISRA-C and Frama-C, which isn't really C anymore, it never works. The proof is the amount of CVE exploits, that get reported almost daily! Just yesterday while reading some papers on Cyclone, I discovered this jewel: "X El Capitan v10.11.6 and Security Update 2016-004" release notes https://support.apple.com/en-us/HT206903 https://support.apple.com/en-us/HT206903 From 36 bug fixes, 31 are related C memory corruption issues!

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.

pjmlp 10y ago

While it is in part true, no amount of band-aid solutions will fix the issue of using C.

snvzz 10y ago
A small TCB will still be key, regardless of language.
- pjmlp 10y ago
  10% small TCB size vs 100% of the complete code. Which one will a security minded person pick?
  - snvzz 10y ago
    Sorry, can you restate that question? I'm not sure what you're asking.
    - pjmlp 10y ago
      A small TCB -> around 10% unsafe code. C, due to arrays, strings, arithmetic operations and memory allocations requiring unsafe code leads to 100% unsafe code across the existing code. A security minded person will pick those 10%.
      - snvzz 10y ago
        > C, due to arrays, strings, arithmetic operations and memory allocations requiring unsafe code leads to 100% unsafe code across the existing code. Imply is just slightly too harsh. Writing safe C code is very possible, as proven by projects such as seL4 or engineers such as djb.
        pjmlp 10y ago
        Those projects had to constrained themselves to having 100% of the code available, no binary libraries and lock the compiler versions being used. Since the early 90's I keep hearing that it is possible to write safe C code, yet outside in the real world, unless constrained by processes like MISRA-C and Frama-C, which isn't really C anymore, it never works. The proof is the amount of CVE exploits, that get reported almost daily! Just yesterday while reading some papers on Cyclone, I discovered this jewel: "X El Capitan v10.11.6 and Security Update 2016-004" release notes https://support.apple.com/en-us/HT206903 https://support.apple.com/en-us/HT206903 From 36 bug fixes, 31 are related C memory corruption issues!