3 ms·

Reading and trying to understand this: 1. The address space for each process has an unprivileged "user-level" segment (DSAPP), and a privileged "OS" segment (D

Reading and trying to understand this: 1. The address space for each process has an unprivileged "user-level" segment (DSAPP), and a privileged "OS" segment (DSOS) where the data traditionally associated with the kernel is stored. 2. Traditional "system calls" are implemented as ordinary procedures. These procedures switch to the privileged segment, do their stuff, and then switch back to the user segment. 3. Since these are ordinary procedures, what's to prevent application code from switching to the privileged segment and mucking with the OS guts? Well, the app doesn't know which segment is privileged! It can try to read it out of the "system call" procedures, but that memory is execute-only, so that won't work. 4. Maybe the app determines the privileged segment via guess-and-check! To prevent that, the OS plays shell games, switching which segment is privileged around every time the app guesses wrong. 5. Ok, so there aren't that many segments: the probability of guessing right is still ~.01% per try. That's very unlikely, assuming the app only guesses once. (We hope attackers haven't thought of guessing more than once.) This guess-and-check attack would seem to be a deal-breaker, no? This seems like a terribly insecure design.

vezzy-fnord 11y ago
You mostly have it right. It's mostly a PoC for a nokernel architecture, and a rather admirable affront at taming the darker corners of x86 segmentation to create a system where you have a per-address space "event core" rather than a traditional kernel, thus largely not performing so much as multiplexing. Though, I think an important addendum is that the selector relocation is context-global and thus the probabilistic mitigation cannot be thwarted by spacing the workload across threads. ---- (EDIT: Actually, I just reread it and in fact the event core will terminate a process after three successive "segment not present" faults, so that should be effective.) ---- By their testimony it is not any more susceptible to standard memory corruption errors than traditional monolithic OSes. One could then argue that the probabilistic weakness requires a malicious application that higher level security policy could weed out, but even further that the value added of a nokernel exceeds the downside of this hole relative to the monolithic kernel state of the industry which is already susceptible to a host of other vulnerabilities. It would, however, discount this KLOS in particular from any high-assurance use cases, but again so are monolithic kernels to begin with. I think the gist of this is that the nokernel architecture is viable, but perhaps COTS architectures are not that expressive. Certainly not x86 it seems.
- nickpsecurity 11y ago
  Good analysis based on what I skimmed earlier.
- benmmurphy 11y ago
  it's not effective. you can just start another process and try again right? i think after 16k attempts you have about 2/3 chance of succeeding. kind of cool but not secure.

vezzy-fnord 11y ago

You mostly have it right. It's mostly a PoC for a nokernel architecture, and a rather admirable affront at taming the darker corners of x86 segmentation to create a system where you have a per-address space "event core" rather than a traditional kernel, thus largely not performing so much as multiplexing. Though, I think an important addendum is that the selector relocation is context-global and thus the probabilistic mitigation cannot be thwarted by spacing the workload across threads. ---- (EDIT: Actually, I just reread it and in fact the event core will terminate a process after three successive "segment not present" faults, so that should be effective.) ---- By their testimony it is not any more susceptible to standard memory corruption errors than traditional monolithic OSes. One could then argue that the probabilistic weakness requires a malicious application that higher level security policy could weed out, but even further that the value added of a nokernel exceeds the downside of this hole relative to the monolithic kernel state of the industry which is already susceptible to a host of other vulnerabilities. It would, however, discount this KLOS in particular from any high-assurance use cases, but again so are monolithic kernels to begin with. I think the gist of this is that the nokernel architecture is viable, but perhaps COTS architectures are not that expressive. Certainly not x86 it seems.

nickpsecurity 11y ago
Good analysis based on what I skimmed earlier.
benmmurphy 11y ago
it's not effective. you can just start another process and try again right? i think after 16k attempts you have about 2/3 chance of succeeding. kind of cool but not secure.