4 ms·

Spectre is fundamental to processor design, but Meltdown is pretty much a bug.

wklauss 9y ago
It is only a bug once you have discovered that branch prediction can be used as a vector of attack. Until then, it was a perfectly valid design implementation.
- pritambaral 9y ago
  It was a bug right from the original design, because it sidestepped the privilege level separation guarantees of the CPU. That the bug could not be exploited for other reasons does not make it not-a-bug.
- jotm 9y ago
  What actual data can be extracted by a Meltdown/Spectre attack? Still need to find an answer to that, nothing online says anything specific. Datacenters should probably be worried, but what about the hundreds of millions of users out there? Doesn't seem like a big deal, tbh - until an actual exploit is out there, why should they worry?
  - scott_s 9y ago
    The page from the researchers is your best source: https://meltdownattack.com/ https://meltdownattack.com/. I also recommend reading the actual papers (https://meltdownattack.com/meltdown.pdf https://meltdownattack.com/meltdown.pdf and https://spectreattack.com/spectre.pdf https://spectreattack.com/spectre.pdf). I haven't gotten to the Spectre paper yet, but the Meltdown paper is excellent, readable, and clear.
  - tptacek 9y ago
    Meltdown allows userland native code (the Javascript your browser loads from random websites is JIT'd down to native code) to dump kernel memory.
    - DSMan195276 9y ago
      It is worth clarifying, when people talk about "kernel memory", for x86-64 it really means all of memory, because all of physical memory is mapped into the kernel's address space. So really, meltdown allows userland code to read anything in memory.
      - zerohp 9y ago
        Incorrect. When people talk about kernel memory, they are talking about pages marked as supervisor in the page tables for a particular process. That is not "anything in memory."
        Dylan16807 9y ago
        I think you missed the "all of physical memory is mapped into the kernel's address space" For a typical kernel without Meltdown mitigations, the entire kernel, including that window into all of physical memory, is in the page tables of every 64 bit process at all times.
        Filligree 9y ago
        Meltdown allows applications to read any mapped pages, regardless of the protection bits on those pages. That mainly means kernel memory, which is the only page set that's normally unreadable. The kernel mapping normally includes all of physical memory.
    - pqh 9y ago
      How do people find the addresses to even start probing for stuff like this?
  - seanp2k2 9y ago
    Theoretically, any application data stored in memory. An example might be a key used to encrypt user data server-side. The scary part of this attack is how it basically breaks the assumptions that most software was written under around memory isolation. Consider an AWS instance that shares a physical system with a different customer’s instance. Amazon, Google, Microsoft, and basically everyone else is scrambling to fix these issues because of the potential. Basically, it’s going to take years to cover the long tail for this issue, and waiting until exploit kits are commonplace isn’t necessary to understand the potential impact.
rayiner 9y ago
I don’t think it’s fair to call Meltdown a bug. It’s like LLVM aggressively taking advantage of undefined behavior in C. Processors, like compilers, are designed making assumptions about what they owe the user and what they don’t. The architecture manuals promise that a user space read from protected kernel memory will trigger a page fault. They don’t make any other promises.
- throwaway2048 9y ago
  Not calling it a bug is ridiculous, it breaks x86 memory protection totally.
  - rayiner 9y ago
    What does “x86 memory protection” mean? What promises does the hardware make to the software?
    - pcwalton 9y ago
      That software in ring 3 cannot read memory in ring 0 unless the appropriate permission bits on the page table entries are set.
      - rayiner 9y ago
        I don't think the spec actually makes that guarantee anywhere. It says that a page fault will be generated if a memory access violates page protection bits, but doesn't discuss any other potential side effects. The closest thing I can find is Intel Architecture Reference Manual Volume 3, Section 5.1.1: > With page-level protection (as with segment-level protection) each memory reference is checked to verify that protection checks are satisfied. All checks are made before the memory cycle is started, and any violation prevents the cycle from starting and results in a page-fault exception being generated. Because checks are performed in parallel with address translation, there is no performance penalty. If you read section 11 on caching, the terminology "memory cycle" seems to exclude cache access. Indeed, Volume 3, Section 11.7 explicitly warns that implicit caching might happen that you would not expect: > Implicit caching occurs when a memory element is made potentially cacheable, although the element may never have been accessed in the normal von Neumann sequence. Implicit caching occurs on the P6 and more recent processor families due to aggressive prefetching, branch prediction, and TLB miss handling.

It is only a bug once you have discovered that branch prediction can be used as a vector of attack. Until then, it was a perfectly valid design implementation.

pritambaral 9y ago
It was a bug right from the original design, because it sidestepped the privilege level separation guarantees of the CPU. That the bug could not be exploited for other reasons does not make it not-a-bug.
jotm 9y ago
What actual data can be extracted by a Meltdown/Spectre attack? Still need to find an answer to that, nothing online says anything specific. Datacenters should probably be worried, but what about the hundreds of millions of users out there? Doesn't seem like a big deal, tbh - until an actual exploit is out there, why should they worry?
- scott_s 9y ago
  The page from the researchers is your best source: https://meltdownattack.com/ https://meltdownattack.com/. I also recommend reading the actual papers (https://meltdownattack.com/meltdown.pdf https://meltdownattack.com/meltdown.pdf and https://spectreattack.com/spectre.pdf https://spectreattack.com/spectre.pdf). I haven't gotten to the Spectre paper yet, but the Meltdown paper is excellent, readable, and clear.
- tptacek 9y ago
  Meltdown allows userland native code (the Javascript your browser loads from random websites is JIT'd down to native code) to dump kernel memory.
  - DSMan195276 9y ago
    It is worth clarifying, when people talk about "kernel memory", for x86-64 it really means all of memory, because all of physical memory is mapped into the kernel's address space. So really, meltdown allows userland code to read anything in memory.
    - zerohp 9y ago
      Incorrect. When people talk about kernel memory, they are talking about pages marked as supervisor in the page tables for a particular process. That is not "anything in memory."
      - Dylan16807 9y ago
        I think you missed the "all of physical memory is mapped into the kernel's address space" For a typical kernel without Meltdown mitigations, the entire kernel, including that window into all of physical memory, is in the page tables of every 64 bit process at all times.
      - Filligree 9y ago
        Meltdown allows applications to read any mapped pages, regardless of the protection bits on those pages. That mainly means kernel memory, which is the only page set that's normally unreadable. The kernel mapping normally includes all of physical memory.
  - pqh 9y ago
    How do people find the addresses to even start probing for stuff like this?
- seanp2k2 9y ago
  Theoretically, any application data stored in memory. An example might be a key used to encrypt user data server-side. The scary part of this attack is how it basically breaks the assumptions that most software was written under around memory isolation. Consider an AWS instance that shares a physical system with a different customer’s instance. Amazon, Google, Microsoft, and basically everyone else is scrambling to fix these issues because of the potential. Basically, it’s going to take years to cover the long tail for this issue, and waiting until exploit kits are commonplace isn’t necessary to understand the potential impact.

rayiner 9y ago

I don’t think it’s fair to call Meltdown a bug. It’s like LLVM aggressively taking advantage of undefined behavior in C. Processors, like compilers, are designed making assumptions about what they owe the user and what they don’t. The architecture manuals promise that a user space read from protected kernel memory will trigger a page fault. They don’t make any other promises.

throwaway2048 9y ago
Not calling it a bug is ridiculous, it breaks x86 memory protection totally.
- rayiner 9y ago
  What does “x86 memory protection” mean? What promises does the hardware make to the software?
  - pcwalton 9y ago
    That software in ring 3 cannot read memory in ring 0 unless the appropriate permission bits on the page table entries are set.
    - rayiner 9y ago
      I don't think the spec actually makes that guarantee anywhere. It says that a page fault will be generated if a memory access violates page protection bits, but doesn't discuss any other potential side effects. The closest thing I can find is Intel Architecture Reference Manual Volume 3, Section 5.1.1: > With page-level protection (as with segment-level protection) each memory reference is checked to verify that protection checks are satisfied. All checks are made before the memory cycle is started, and any violation prevents the cycle from starting and results in a page-fault exception being generated. Because checks are performed in parallel with address translation, there is no performance penalty. If you read section 11 on caching, the terminology "memory cycle" seems to exclude cache access. Indeed, Volume 3, Section 11.7 explicitly warns that implicit caching might happen that you would not expect: > Implicit caching occurs when a memory element is made potentially cacheable, although the element may never have been accessed in the normal von Neumann sequence. Implicit caching occurs on the P6 and more recent processor families due to aggressive prefetching, branch prediction, and TLB miss handling.