4 ms·

The kernel faulting is effectively burning down. In modern systems there is the concept of "isolation", if you give bad input to one program (e.g. the shell) th

The kernel faulting is effectively burning down. In modern systems there is the concept of "isolation", if you give bad input to one program (e.g. the shell) the kernel shouldn't fault (taking down unrelated programs with it).

tscs37 9y ago
There is (most likely) no perfect isolation. If given no alternatives, a kernel should burn down rather than permitting a privilege escalation. Ideally there is no privilege escalation either. Given bad input the kernel should not fault but sometimes it must.
- infinity0 9y ago
  Imperfect isolation is always treated as a bug. As a kernel developer if you try to argue otherwise you'll get laughed out of the room and/or fired. Hopefully both.
  - tscs37 9y ago
    I'm not saying imperfect isolation isn't a bug. Rather that bugs are inevitable and the proper responce to some bugs being exploited (maliciously or not) is to crash the kernel if there is no other option.
  - lordnaikon 9y ago
    Hardware can misbehave. If the kernel can detect that it is reasonable to shut down the machine and preventing data corruptions. I cannot think of a kernel developer who would laugh at that.
- EtDybNuvCu 9y ago
  Capability-safe languages in the E family, like E and Monte, have perfect isolation, or as it's known in the community, "working encapsulation." In a capability-safe system, only bugs in the implementation, such as runtime or CPU bugs, can violate isolation. Here's an introduction to E: http://www.erights.org/talks/promises/paper/tgc05-submitted.pdf http://www.erights.org/talks/promises/paper/tgc05-submitted.... The Monte language's manual starts with a tutorial and an explanation of what capability-safe languages do: http://monte.readthedocs.io/ http://monte.readthedocs.io/
  - tscs37 9y ago
    That's all nice but what if you have a CPU bug like Spectre? Isolation is nice in userspace but in kernelspace the rules are somewhat different, especially considering that it is the task of kernelspace to mediate and abstract hardware access to arbitrary programs running on your system. Any number of hardware bugs may break isolation. Any number of wrong assumption or subtle logic bugs can happen and break the isolation. The documentation on Monte also mentions that it is rather slow and requires memory management, two properties that simply do not exist in kernel space. Writing a kernel is like writing a modern web browser except if you get it wrong the malicious program can access everything, all webpages, all the history and send your mom rude jokes on facebook after literally setting your computer on fire. So you can't simply say "we will never break isolation", you must question "in the absolutely infinitely small occurence that isolation breaks, what do we do?". A Kernel must be prepared to deal with such a possibility. Even if it "cannot happen".
    - zerokernel 9y ago
      That's why high assurance systems (like L4/seL4) minimize privileged code to a tiny fraction of what you find in a regular system, which absolutely makes sense and provably improves security. Apart from the obvious advantages, minimal privileged code also means that it becomes far more feasible to formally verify the privileged code, like it has been done for seL4, which in turn is an important cornerstone to ensure that isolation (or more generally, specification invariants) does not break in any reachable system state.
      - tscs37 9y ago
        Even a perfect kernel will have to crash. Something like Rowhammer can turn perfectly written code into malicioous gadgets for an attacker. Until ECC or preventative measures becomes widespread in consumer hardware, this attack will remain viable. Additionally, cosmic rays may at any time write arbitrary data into memory. In these situations it is perfectly reasonable to crash the machine if essential datastructures were affected. Or suppose you just received a MACHINE CHECK exception, the type of interrupt which essentially just tells the OS that the machine is no longer capable of operating in it's current state. This isn't all about an attacker gaining privilege, the mere act of crashing the kernel in a hostile or other event (cosmic rays, voltage fluctuation) which leads to corruption or compromise of the continued operation of the machine is perfectly acceptable and normal.

tscs37 9y ago

There is (most likely) no perfect isolation. If given no alternatives, a kernel should burn down rather than permitting a privilege escalation. Ideally there is no privilege escalation either. Given bad input the kernel should not fault but sometimes it must.

infinity0 9y ago
Imperfect isolation is always treated as a bug. As a kernel developer if you try to argue otherwise you'll get laughed out of the room and/or fired. Hopefully both.
- tscs37 9y ago
  I'm not saying imperfect isolation isn't a bug. Rather that bugs are inevitable and the proper responce to some bugs being exploited (maliciously or not) is to crash the kernel if there is no other option.
- lordnaikon 9y ago
  Hardware can misbehave. If the kernel can detect that it is reasonable to shut down the machine and preventing data corruptions. I cannot think of a kernel developer who would laugh at that.
EtDybNuvCu 9y ago
Capability-safe languages in the E family, like E and Monte, have perfect isolation, or as it's known in the community, "working encapsulation." In a capability-safe system, only bugs in the implementation, such as runtime or CPU bugs, can violate isolation. Here's an introduction to E: http://www.erights.org/talks/promises/paper/tgc05-submitted.pdf http://www.erights.org/talks/promises/paper/tgc05-submitted.... The Monte language's manual starts with a tutorial and an explanation of what capability-safe languages do: http://monte.readthedocs.io/ http://monte.readthedocs.io/
- tscs37 9y ago
  That's all nice but what if you have a CPU bug like Spectre? Isolation is nice in userspace but in kernelspace the rules are somewhat different, especially considering that it is the task of kernelspace to mediate and abstract hardware access to arbitrary programs running on your system. Any number of hardware bugs may break isolation. Any number of wrong assumption or subtle logic bugs can happen and break the isolation. The documentation on Monte also mentions that it is rather slow and requires memory management, two properties that simply do not exist in kernel space. Writing a kernel is like writing a modern web browser except if you get it wrong the malicious program can access everything, all webpages, all the history and send your mom rude jokes on facebook after literally setting your computer on fire. So you can't simply say "we will never break isolation", you must question "in the absolutely infinitely small occurence that isolation breaks, what do we do?". A Kernel must be prepared to deal with such a possibility. Even if it "cannot happen".
  - zerokernel 9y ago
    That's why high assurance systems (like L4/seL4) minimize privileged code to a tiny fraction of what you find in a regular system, which absolutely makes sense and provably improves security. Apart from the obvious advantages, minimal privileged code also means that it becomes far more feasible to formally verify the privileged code, like it has been done for seL4, which in turn is an important cornerstone to ensure that isolation (or more generally, specification invariants) does not break in any reachable system state.
    - tscs37 9y ago
      Even a perfect kernel will have to crash. Something like Rowhammer can turn perfectly written code into malicioous gadgets for an attacker. Until ECC or preventative measures becomes widespread in consumer hardware, this attack will remain viable. Additionally, cosmic rays may at any time write arbitrary data into memory. In these situations it is perfectly reasonable to crash the machine if essential datastructures were affected. Or suppose you just received a MACHINE CHECK exception, the type of interrupt which essentially just tells the OS that the machine is no longer capable of operating in it's current state. This isn't all about an attacker gaining privilege, the mere act of crashing the kernel in a hostile or other event (cosmic rays, voltage fluctuation) which leads to corruption or compromise of the continued operation of the machine is perfectly acceptable and normal.