Eyes, JAPAN Blog > Surprise at the beginning of the year (some words about Meltdown vulnerability)

Surprise at the beginning of the year (some words about Meltdown vulnerability)

Mola BogdanGeorgii



Today I would like to tell about some events that provide hype at the beginning of this year. I am talking about Meltdown vulnerability showed that almost all CPU produced since 1993 (except microcontrollers) has weak point at microarchitecture level. Does it mean something terrible? No, it is not end of the World. However, it is still very unpleasant and interesting problem.


Essence of the problem

Foundation of computer’s security based on isolation of memory provided for users processes. It gives guarantee that CPU does not provide access to process A to memory o process B (Exception: it is explicitly provided access). Without this basic rule, everything other is meaningless. In particular, this mechanism implementer on hardware level as MMU (Memory Management Unit) which allocate memory for new process and prevent any attempts to rich not assigned zone of memory. As result, user’s processes cannot get direct access to memory, which contain system core. For performance reasons CPU uses algorithms that sometime ignores MMU and information about such events can indirectly obtained. This takes into account probability of frequently performed conditions. This information allows CPU do not wait result of condition calculation and just go to next command. What if prediction is wrong? CPU just reset its state and begin from step with condition. For example:

If(x< someArray.size())
     someVar = someArray[x];

So, using execution of such code in speculative way (creating situation with positive resolution of condition) CPU assign high probability of positive resolution. As result, CPU will ignore condition. Theoretically, we can provide some illegal x in right moment and CPU will read some other part of memory that is prohibited for current process. How much commands can perform modern CPU? Roughly pair of tens. Actually, at this stage everything is ok. Process does not has information about these mechanisms inside CPU. Results of executed commands unreachable. Only some lack of performance process observe. It is exactly moment when CPU understand that x is wrong and reset it’s state. But there one independent module which will store data. It is cash. In case of using speculative code the next things occurs:

  1. Read memory with x address
  2. MMU provides reading as illegal operation
  3. CPU reset it’s state

Nevertheless, cash will still store value of x address. There are no direct access to cash. But if reading of x address occurs it is possible to check was it reading from RAM or cash (cash provides faster speed). It still impossible to reach X address, isn’t it? Last step is using of indirect addresses and some system’s feature. By default (until this problem has been revealed), every process has own part of memory divided by two zones with different privileges. One is with “regular” privileges and other with system core privileges (It is allows to increase performance by performing system calls inside allocated memory).

Lets consider the next scenario: we have memory ranges 0..99 for process needs and  100..200 for system. We deliberately perform some amount of access operation with positive result.  And then try access to address 150. Next steps:

  1. CPU will read value with address 150,  lets say value is 88
  2. CPU read value of address 88 (remember we use indirect addresses)
  3. MMU indicates illegal reading of 150


  1. CPU reset state and output error


  1. Process begin to read memory in legal range in random order to “train” probability estimation of CPU.


  1. When it reach address 88 access time is lower (Provided by cash).


This event allow drawing conclusion that reading of this address occurred before. So, address 150 store value of 98. So, indirect addressing is last piece in method of reading all system core memory.

Effects and Threats.

Good news it is read-only access. However, there are assumption that this memory is safety (was safety) and sometime it is used for storing some private data as passwords. Important point there is possibility of using this attach only locally. (JavaScript is possible way, that’s why browser first of all get rid of this weak point). Despite to fact that this problem has microarchitecture hardware level it still can be solved by software. Security updates for operation systems has been developed as soon as it was possible.



This case bring me the next ideas: even time-proved things can become suddenly unreliable, it was additional reminder that there are no limits for self-improvements and it is fine to have “plan B”  J

Thanks for reading

  • このエントリーをはてなブックマークに追加