Meltdown-Spectre/explainedについて、ここに記述してください。

きちんとした解説のように見える。(自分がきちんと理解できているとは言えないので) -- ToshinoriMaeno 2018-01-24 01:53:47

https://medium.com/@mattklein123/meltdown-spectre-explained-6bc8634cc0c2 

In this post I’m going to attempt to correct that by providing a gentle introduction to the hardware and software background required to understand the vulnerabilities, a discussion of the vulnerabilities themselves, as well as a discussion of the current mitigations.

Background

Virtual memory

Translation Lookaside Buffer (TLB) 1_-EkJxntbntPppqfPgTjbWg.png

In this example, we start seeing some of the useful features of virtual memory. Primarily:

    User memory in each process is in the virtual range 0–99, but backed by different physical memory.
    Kernel memory in each process is in the virtual range 100–199, but backed by the same physical memory.

Even though kernel memory is mapped into each user process,

At this point I will note that this type of dual mapping (each process having the kernel mapped into it directly) has been standard practice in operating system design for over thirty years for performance reasons (system calls are very common and it would take a long time to remap the kernel or user space on every transition).

CPU cache topology

Speculative execution

   if (x < array1_size) {
      y = array2[array1[x] * 256];
   }

imagine that array1_size is not available in cache, but the address of array1 is.

Another type of speculative execution is known as indirect branch prediction.

class Base {
 public:
  virtual void Foo() = 0;
};

class Derived : public Base {
 public:
  void Foo() override { … }
};

Base* obj = new Derived;
obj->Foo();

Meltdown vulnerability

Rogue data cache load

Spectre vulnerability

Bounds check bypass (Spectre variant 1)

I consider this a fundamental revelation about how modern hardware and software work together.