Specter and Meltdown

Everything is as always, we hear a ringing, but we do not know where he is.

The network has another drain of information about two vulnerabilities in the hardware of modern processors. Actually the vulnerability was open for public discussion one, but two methods of its operation were disclosed, under the names Specter and Meltdown.
For specialists, this equipment problem has been known for a long time, it was "quietly" operated and everyone was happy ...

For some unknown reason, it was decided to exaggerate the hype, and in an amateurish way, those who issued official press releases ( spectre.pdf and meltdown.pdf ) clearly had little idea how it all worked and where the problem was.

And the suppliers of the initial information did not bother to explain the problem in detail, apparently they gave a working exploit and a short description for amateurs ...

Homebrew commentators and assembler experts began to intelligently explain how it all works.
')
Here, for example, an article with a bunch of comments. Especially touches it:



The “naive Chukchi guy” does not understand why the 1000h shift, and indeed how it all works, simply translates in his own words the same illiterate text of the original press release.

We'll have to explain.

Real location of vulnerability in hardware

The vulnerability is located here, it is highlighted with a red circle:



The problem is in the TLB block, which is used in paging addressing of RAM. It is an associative buffer storing pairs of values ​​of the virtual-physical address used by the application in RAM. This is not a data cache ....

Here is how Intel’s documentation describes it:



The TLB block is needed in order to shorten the time for accessing the OP by eliminating the procedure for translating memory addresses. Such a broadcast is made only once for the entire page (just 4K in size in the case of modern OS). All other program calls to memory in this page are already being forced, using the stored value in this buffer. These blocks are in all modern processors, because of this, they are all susceptible to the vulnerabilities called Specter and Meltdown.

And by the way, speculative execution of commands is not the only way to exploit these vulnerabilities, you can use the mechanism of forward data loading from the OP.

The TLB block does not have a program (firmware) control, like a normal cache. It is impossible to delete a record from it, or to force / make / modify any record.

This is a hardware vulnerability, all address translation produced is stored in this associative buffer.

Accordingly, the speculative operation carried out will also be left in the TLB block following in the form of a record; you only need to detect and identify this record. And this is already a “matter of technology”, the technology has long been known and used, it is called “Study of the state of the equipment by the method of temporary ringing”. Do not look for this name on the Internet, the method was known in very narrow circles of completely non-public experts.

But now everyone will know him ...

The only possibility of programmatic influence on the TLB block is a complete reset of all its values ​​(well, here I’m a little cunning only for ease of understanding). All patches for Specter and Meltdown vulnerabilities proposed by software makers do this by resetting the CR3 register in the GP exception exception handler.

After resetting the TLB, the processor has to re-execute the translation of all used virtual memory pages, and this reduces system performance.

How all this is exploited in reality

The first thing you need to do in the program is to create a buffer of 2 megabytes in size, and you cannot write / read to this buffer before the attack and it should be located on the border of the 4K block. This size is fundamental, exactly 256 pages of 4K should be placed in the buffer (specificity of paging addressing).

Then execute commands like:



In the program after the command Mov al, [OS kernel address]; an interrupt will occur and the value of the al register will not change (will remain zero).

But in the TLB buffer, due to a forward request for performing the operation, the computed correspondence between the virtual address and the physical address [ebx + eax] will be stored.
It is impossible to reset this particular record, as it is done in a regular Kesh, in a TLB block, and it will remain ...

Accordingly, if we know the address of a 4K page in a 2M buffer, stored in a TLB block, we will also know the value read from the OS kernel into the register al.
This is already a matter of technology, “let's call” the TLB block. To do this, you need to read all its 4K pages once, exactly 256 of them, we will perform 256 read operations (one for each 4K block). At the same time, we will measure the time of the read operation. The page that will be read faster than the rest, and will have a number in the 2M buffer corresponding to the read byte value from the OS kernel.

This will happen because the TLB buffer for this page has already calculated the correspondence between the virtual and physical addresses, and for all other pages this operation has not yet been performed.

In the “ringing” of course not everything is so simple, there are many nuances, but it is quite possible.
Did, we know ...

That's all.