9 ms·

> CPU-level vulnerabilities and the performance-concerns are in-directly solved by hardware advancements/implementations given for free or optimising the OS to

• drewg123 7y ago
  Indeed, mitigations slow down boundary crossings of protection domains (kerne/user, user/user), which slows down context switches, which are the very thing that are performance critical for microkernels.
  • phkahler 7y ago
    I have to wonder if rusts safety guarantees and approach to concurrency will allow some performance optimization across those boundaries. They seem like related problems.
    • chc4 7y ago
      There are some very smart research kernels based around only allowing managed, safe code to be ran, so that language security does all the heavy lifting instead of hardware security. The problem then, though, is that every language unsafety bug is now a kernel bug that lets you read other processes' private keys or write to kernel memory. Rust is supposed to be safer. There are still plenty of type system unsoundness issues or LLVM unsafety issues that leak through every so often.
      • heavenlyblue 7y ago
        How is hardware security different from language security? Hardware is simply Yet Another Language.
      • jabl 7y ago
        You could replace virtual memory as an isolation mechanism with capabilities? That would allow unsafe languages like C to be used, as the hw would enforce that capabilities are unforgeable. E.g. CHERI.
    • ori_b 7y ago
      No; the performance problems are there because the guarantees provided by any safe language are insufficient to prevent information leakage.
      • andrekandre 7y ago
        > the guarantees provided by any safe language are insufficient to prevent information leakage i’m curious why? i understand if a “safe language” provided unsafe capabilities (like marking a section with unsafe keyword to access registers or raw memory) then of course that’s a problem... but if you don’t have global variables and memory access, shouldn’t it be possible to cover it with just software? maybe i’m missing something? (and apologies if the answer is obvious ^^)
        • ori_b 7y ago
          > but if you don’t have global variables and memory access, shouldn’t it be possible to cover it with just software? Can you index out of bounds and catch the exception? You're attackable via Spectre. Can you run multiple threads and time operations? You're vulnerable to MDS. The attacks don't rely on memory unsafety -- they rely on the state of the CPU being changed by doing fairly normal things, while an observer probes the state by doing other fairly normal things.
          • andrekandre 7y ago
            thanks for the reply, it’s appreciated! > Can you index out of bounds and catch the exception? You're attackable via Spectre. ah, i see... ok assuming you could never access out of bounds (all arrays must be typed by length) would that still apply? or do you mean any kind of exception handling that can be deterministically invoked? what if a hypothetical safe language had no exceptions? > Can you run multiple threads and time operations? You're vulnerable to MDS. would that more or less depend on wether or not hyper-threading is enabled or not? assuming you can choose which cpu you are using(that is not vulnerable like intel) would that negate needing hardware memory protection when used with a “safe” language? > The attacks don't rely on memory unsafety -- they rely on the state of the CPU being changed by doing fairly normal things, while an observer probes the state by doing other fairly normal things. yes, thanks. i was just wondering what the limits to that re in terms of “safe’ languages vis-a-vis hardware memory protection/os etc...