5 ms·

So I have read the meltdown.pdf paper, but I don't quite understand why/how it bypasses the kernel/usermode checks of the pagetable, does anyone have a good exp

So I have read the meltdown.pdf paper, but I don't quite understand why/how it bypasses the kernel/usermode checks of the pagetable, does anyone have a good explanation ? Furthermore the paper mentions it is unable to reproduce it on AMD and ARM, but has some suggestions of things to try to make the exploit work. Other sources , including AMD itself, claims not to be vulnerable to meltdown, does anyone know the technical reasons as to why, and what is different compared to Intel cpus ?

craigyk 9y ago
I wrote up this analogy, but basically it only checks after it has done the work of verifying a conditional, and the result of that conditional is to cache something you have can check the access time to. Let's say you want to know if your boss is away on vacation next week so you call their admin and say "you need to double-check my contact info if the boss is going to be out next week". They load up the boss' calendar to check and based on his presence next week then load up your info. Only once done, do they take the time to remember the boss didn't want you to know wether they are in or out. So you hear back, "sorry, can't tell you that, but you follow up with "OK, well can you still double check that my phone number is..." If they respond quickly with a yes, then your file is still on their screen and the boss is in fact out next week. If there is a short pause while they look it up, then the opposite.
kimdcmason 9y ago
What it does is create a branch in code that is never actually followed, but is executed speculatively by the CPU, which then discards the result. The problem is that even though the result is discarded, computation of the result causes a measurable side effect (specifically, it populates caches accessible to the code). In short, the speculatively executed branch retrieves a value from a kernel page (that the code shouldn't have access to) - Intel CPUs allow this, but AMD CPUs do not. It then &s the value with 0x01, and then uses the result to calculate and access an address in a page that it DOES have access to. This results in that address being stored in the TLB (i.e. a cache that stores mapping from virtual to physical memory). The result of the computation is then discarded, but the address that it calculated is still in TLB. Since there are two possible addresses that could have been cached based on the value of the data in the kernel page, all the code has to do is time the access to each address, and it can discern the value of the bit in the kernel page based on the relative timings.
- noselasd 9y ago
  > Intel CPUs allow this, but AMD CPUs do not. Do we know this for sure ? I see now that the meltdown paper has a suggestion in chapter 7.1 that the CPU should perform the permission check on the page table before data is fetched to the cache, But dismisses that suggestion on the grounds it will haves very high performance impact. Are you saying AMD does the check first anyway, and either takes the performance hit or has found a way to not take a performance hit ?
  - kimdcmason 9y ago
    My understanding isn't especially deep, but I believe AMD prevents access to unloaded pages that the code doesn't have permission to access, even for speculative access. Their specific quote is: "AMD processors are not subject to the types of attacks that the kernel page table isolation feature protects against. The AMD microarchitecture does not allow memory references, including speculative references, that access higher privileged data when running in a lesser privileged mode when that access would result in a page fault."
BraveNewCurency 9y ago
Basically, you have some code that says "go read a byte from kernel memory. if the high bit of that byte is true, then access page X of memory". Normally, that code will just error out right away. But if you add a new branch before the code (such that the branch is taken to avoid the code, but the CPU predicts the branch to NOT be taken), the CPU will speculatively execute the above code just past your branch. The speculative execution doesn't check for memory violations (because that takes time). Normally, that's cool: if the new branch IS taken, there is no harm because the the result of the (bad) kernel access will be thrown away. If the new branch IS NOT taken, the CPU notices the bad access and complains. But if you are extra devious, you can ensure that page X is NOT cached when running this code. After, you check if page X suddenly got cached. That tells you the value of the high-bit of your kernel memory. Keep scanning all the bits and you can read out all of kernel memory.
- RachelF 9y ago
  An excellent, succinct explanation!
zeotroph 9y ago
Related question about spectre and the cross-process(!?) mem read possibility: the attacker "influences the victim to execute the gadget speculatively.", and then the "areful selection of a gadget" (i.e. in the victim process) can be used to read arbitrary victim memory. How is that possible? I can understand an attacker reading its own memory, but foreign one via a common mapped gadged section... that is just incredible!

craigyk 9y ago

I wrote up this analogy, but basically it only checks after it has done the work of verifying a conditional, and the result of that conditional is to cache something you have can check the access time to. Let's say you want to know if your boss is away on vacation next week so you call their admin and say "you need to double-check my contact info if the boss is going to be out next week". They load up the boss' calendar to check and based on his presence next week then load up your info. Only once done, do they take the time to remember the boss didn't want you to know wether they are in or out. So you hear back, "sorry, can't tell you that, but you follow up with "OK, well can you still double check that my phone number is..." If they respond quickly with a yes, then your file is still on their screen and the boss is in fact out next week. If there is a short pause while they look it up, then the opposite.

kimdcmason 9y ago

What it does is create a branch in code that is never actually followed, but is executed speculatively by the CPU, which then discards the result. The problem is that even though the result is discarded, computation of the result causes a measurable side effect (specifically, it populates caches accessible to the code). In short, the speculatively executed branch retrieves a value from a kernel page (that the code shouldn't have access to) - Intel CPUs allow this, but AMD CPUs do not. It then &s the value with 0x01, and then uses the result to calculate and access an address in a page that it DOES have access to. This results in that address being stored in the TLB (i.e. a cache that stores mapping from virtual to physical memory). The result of the computation is then discarded, but the address that it calculated is still in TLB. Since there are two possible addresses that could have been cached based on the value of the data in the kernel page, all the code has to do is time the access to each address, and it can discern the value of the bit in the kernel page based on the relative timings.

noselasd 9y ago
> Intel CPUs allow this, but AMD CPUs do not. Do we know this for sure ? I see now that the meltdown paper has a suggestion in chapter 7.1 that the CPU should perform the permission check on the page table before data is fetched to the cache, But dismisses that suggestion on the grounds it will haves very high performance impact. Are you saying AMD does the check first anyway, and either takes the performance hit or has found a way to not take a performance hit ?
- kimdcmason 9y ago
  My understanding isn't especially deep, but I believe AMD prevents access to unloaded pages that the code doesn't have permission to access, even for speculative access. Their specific quote is: "AMD processors are not subject to the types of attacks that the kernel page table isolation feature protects against. The AMD microarchitecture does not allow memory references, including speculative references, that access higher privileged data when running in a lesser privileged mode when that access would result in a page fault."

BraveNewCurency 9y ago

Basically, you have some code that says "go read a byte from kernel memory. if the high bit of that byte is true, then access page X of memory". Normally, that code will just error out right away. But if you add a new branch before the code (such that the branch is taken to avoid the code, but the CPU predicts the branch to NOT be taken), the CPU will speculatively execute the above code just past your branch. The speculative execution doesn't check for memory violations (because that takes time). Normally, that's cool: if the new branch IS taken, there is no harm because the the result of the (bad) kernel access will be thrown away. If the new branch IS NOT taken, the CPU notices the bad access and complains. But if you are extra devious, you can ensure that page X is NOT cached when running this code. After, you check if page X suddenly got cached. That tells you the value of the high-bit of your kernel memory. Keep scanning all the bits and you can read out all of kernel memory.

RachelF 9y ago
An excellent, succinct explanation!

zeotroph 9y ago

Related question about spectre and the cross-process(!?) mem read possibility: the attacker "influences the victim to execute the gadget speculatively.", and then the "areful selection of a gadget" (i.e. in the victim process) can be used to read arbitrary victim memory. How is that possible? I can understand an attacker reading its own memory, but foreign one via a common mapped gadged section... that is just incredible!