6

I read all the week-end about Meltdown and Spectre

I also have already read the .pdfs for Spectre and Meltdown which are Must Read for anyone seeking more knowledge about these exploits but unfortunately don't provide detailed explanations on the code.

I found various PoC on github, which were very interesting but I lack the knowledge to fully understand it. I would be thanksful about more explanation on specific parts:

From this link https://github.com/dendisuhubdy/meltdown/blob/master/src/poc.c , and other git repositories as well, there are many interesting parts in the conception of this exploit.

Time reads

/* Time reads. Order is lightly mixed up to prevent stride prediction */
    for (i = 0; i < 256; i++) {
        mix_i = ((i * 167) + 13) & 255;
        addr = &array2[mix_i * 512];
        time1 = __rdtscp(&junk); /* READ TIMER */
        junk = *addr; /* MEMORY ACCESS TO TIME */
        time2 = __rdtscp(&junk) - time1; /* READ TIMER & COMPUTE ELAPSED TIME */
        if (time2 <= CACHE_HIT_THRESHOLD && mix_i != array1[tries % array1_size])
            results[mix_i]++; /* cache hit - add +1 to score for this value */
    }

why do we use prime numbers 167 and 13 ? 

 /* Locate highest & second-highest results results tallies in j/k */

Why do we care about getting the max value ?

Other parts explanations are very welcome as well !!

Antonin GAVREL
  • 9,682
  • 8
  • 54
  • 81
  • 3
    I would recommend reading the papers (https://meltdownattack.com/meltdown.pdf and https://spectreattack.com/spectre.pdf). They are some of the most well written papers that I have ever read. –  Jan 29 '18 at 14:15
  • thank you @Lalaland, I read them already but I still added hyperlinks to the original post since they are Must Read – Antonin GAVREL Jan 29 '18 at 14:42
  • 1
    The victim function is the target of a Spectre version-1 attack, where the branch predictor is trained to predict a branch at that virtual address to be not-taken, so the speculatively-executed array1 access goes out of bounds, and the array2 access turns that value into a cache-line hot-or-not. This is probably the most straightforward part of the whole thing and matches exactly what's described as a "gadget" in the Spectre paper. (Except the paper focuses more on indirect branch targets, rather that conditional branches.) i.e. it's a textbook example of vulnerable code. – Peter Cordes Jan 29 '18 at 16:18
  • @PeterCordes thank you !! I edited the question to make it more specific. Would you mind removing the "on hold" status ? – Antonin GAVREL Jan 30 '18 at 09:12
  • It's still arguably too broad, because you're asking 3 different questions, and only 2 of them are really related: The sampling in part2 of your question is done repeatedly, and then you take the max as the most likely value. It's a noisy channel, so you need repetition. I did vote to reopen because parts 2 and 3 are part of the same algo. – Peter Cordes Jan 30 '18 at 11:19
  • And BTW, the primes are a simple [Linear Congruential Generator](https://en.wikipedia.org/wiki/Linear_congruential_generator) to traverse every array entry exactly once, but (as the comments explain) not in an order that prefetch would predict; we *want* cache misses for timing, and only a hit if something else made the line hot, not our reads of other entries. – Peter Cordes Jan 30 '18 at 11:22
  • ok I removed part 1 as an effort to make it less broad – Antonin GAVREL Jan 30 '18 at 11:54
  • @AntoninGavrel Most of those tricks are not necessary in fact. They are there either due to the authors were not aware of the simpler workarounds or were targeting broader range of architectures. My PoC for both Spectre and Meltdown (i.e. 2-in-1) takes only 99 lines: https://github.com/berestovskyy/spectre-meltdown and I hope much easier to understand thanks to comments. – Andriy Berestovskyy Feb 03 '18 at 10:49
  • it is not working on Mac OS X with the linux proc banner 0xffffffff81800040. Do you have any idea what it could be replaced with ? – Antonin GAVREL Feb 03 '18 at 16:58

0 Answers0