At first I couldn't understand how "cache line” index is actually the byte read from kernel.
I could wrap my head around the idea that reading a single bit could be somehow possible, because you only need to know if something is 0 or 1. But reading an entire byte only by measuring time difference seemed impossible to me.
I looked up what cache line is, it seems that if the byte stored at an address we're looking on is in the cache, the CPU will deliver it, if not it will go fetch.
Then it hit me, we're actually able to make the machine read the contents of the kernel addresses, because the CPU evaluates (not execute) code ahead of time.
We create an array that is large enough to represent a byte in its index. We try to access the value of the kernel addresses and use it as an index on our array. This succeeds because the CPU hasn't executed our code yet so, no access violation error was thrown. But it evaluated our code, so our instructions actually passed through the CPU during some branch simulation. So the address we accessed on array whose index represents the byte peeked from kernel is on the CPU cache. If we ask the CPU to retrieve that address it will return super fast. It doesn't matter that we couldn't set the content to something. Because C arrays are just bytes stacked on top of a memory address. So if we want to access the nth element of the address, we can use arrays_base_address+element_index*element_size. Then we probe the address of each element of our array. If the address is in the cache it will return much much faster. The array itself is in the userland so no exception for address violation will occur. Once we find the address, we can determine the byte of the kernel address we intended to find. Because we stored the content of the kernel address as an index of an array, which is a memory address.
I have no formal training in CS, so it surprised me that I could understand how Meltdown works. I might have made a lot of mistakes trying to explain this in my limited vocabulary, but I hope this helps someone trying to make sense of the article.