Revisions and Commits
I do not have a PoC (or much interest in making one, I have too many more important things to do), but I believe this to be correct, based heavily on PPC knowledge of Nicolas König <email@example.com> . This attack also applies to AMD, Intel, and ARM.
The encrypt and decrypt tables are stored in the .rodata section of the ELF. If two processes map the same file they get differn't virtual addresses (because of PIC), but the same physical address. CPU caches work with physical addresses, after the MMU translates the address.
While L3 cache is not vulnerable to this attack on PPC, because it isn't unified and not inclusive, L2 (shared between code pairs) and L1 (shared between SMT threads) are, and processes can evict these at will (and do not need to even rely on preemption to evict the AES table). If they evict the table (which they have a handle to via loading the dynamic library) while the other process is doing AES, then they can do the flush and reload attack.
The fix is make the physical address unavailable to other processes by having the prefetch functions copy the table to a global static variable, that will not be shared with other processes.
 PPC has 64 slots (D-ERAT) that are not MMU translated, but that is only 4096bytes, the size of the table, and code also has to be in that cache too, so it doesn't protect from this attack.
Andreas, I wonder on which grounds you assigned a CVE for this claimed side-channel attack. The mentioned paper is about an old RSA side-channel and not on AES. I would like to see more facts than the reference to a guy who knows PPC pretty well.
I assigned the CVE, but yes it needs more facts.
El dom., 23 de jun. de 2019 10:45, werner (Werner Koch) <
werner added a comment.
Andreas, I wonder on which grounds you assigned a CVE for this claimed
side-channel attack. The mentioned paper is about an old RSA side-channel
and not on AES. I would like to see more facts than the reference to a guy
who knows PPC pretty well.
*Cc: *ametzler1, werner, slandden, pmgdeb, Rafixmod, srgblnchtrn, gp_ast,
This is an automated email from the GnuPG development hub. If you have
registered in the past at https://bugs.gnupg.org/ your account was
migrated automatically. You can visit https://dev.gnupg.org/ to set a new
password and update your email preferences.
Werner, I interpreted jwilik's patch as admission of a problem from upstream, and reported it as such to CVE. I felt that since this does not effect the main platforms (ARM and x86_64) it would not be a big deal. If I interpreted wrong, I am sorry.
As of now we doubt that the proposed patch helps and we even fear that it could make things worst. Thus, as long as there is we have no description of an attack we won't do anything about it.