A security problem in a program is a minor problem, after all the software is intangible and changing the code does not cost anything. On the other hand, every processor is a complex physical piece where any error in its operation cannot be easily repaired. When a failure is discovered in a processor that is for sale, it may affect new designs in production and take several years to fix. Intel had been affected by a security problem that was baptized as Meltdown in 2018, well, it seems that now AMD CPUs have their own version of the problem.
They discover a Meltdown-type security problem in AMD CPUs
Two cybersecurity researchers from the Dresden University of Technology, Saidgani Musaev and Christof Fetzer, have discovered a security vulnerability affecting some AMD CPUs, specifically those based on the Zen + architecture that correspond to the series AMD Ryzen 2000 Desktop and the zen architecture 2, corresponding to the series AMD Ryzen 3000, 4000 for Desktops and Laptops. Which is also implemented in the APUs of a good part of the new generation consoles. As well as some models of the Threadripper and EPYC using these architectures.
The discovery of said vulnerability has been published in a Paper entitled Transient Execution of Non-Canonical Acceses. Under this complex name refers to speculative execution. Which is that the CPU executes instructions beforehand and that it is not supposed to execute because it depends on the operation of the previous code. In order to take advantage of all the power of the processor and not have it stopped, all the possibilities are executed in a separate execution branch.
The problem with these methods? Meltdown-type security attacks typically attack shared data buffers in both normal and speculative execution. For example, Meltdown in its classic form performs its attack on the data cache, but the security problem on AMD CPUs seems to affect a different cache.
How is the security problem in AMD CPUs?
Because both Intel and AMD have a totally different control unit, even if it decodes the same set of instructions. AMD CPUs are not affected by the classic Meltdown, but there is a loophole that can lead to the execution of illegal code and this occurs when an instruction is loaded to be executed during the instruction cycle. Specifically, in the Zen + and Zen 2 cores, a load is carried out on the TLB cache.
How does the exploit work? Apparently there is a check between the address bits of the instruction and the contents of the TLB cache line, what happens is that it only checks the last 48 bits and ignores the 16 different ones. Therefore, an address that has the first 16 bits different from the one in the TLB cache can be sent for this check and that passes the check as long as the remaining 48 match.
This is called non-canonical violation of memory addressing, keep in mind that a 48-bit memory address is to have access to 256 TB of storage. So in theory we are talking about a data that would be in that memory address and would not cease to be a curiosity. The problem is exacerbated if we take into account that the mirror memory map is often used. This means that instead of a memory map for all memory, there are several successive maps and several virtual memory addresses point to a specific physical memory address.
AMD will not update the microcode of its CPUs
Through a press release on their website, AMD states that they have studied the problem and have stated the following:
AMD recommends that software vendors analyze their code for any potential vulnerabilities related to this type of transient execution. Potential vulnerabilities can be addressed by inserting a LFENCE or using speculative execution mitigation techniques. As described in the manual titled SOFTWARE TECHNIQUES FOR MANAGING SPECULATION ON AMD PROCESSORS
This means that from AMD they will not carry out a massive update of the microcode of the control unit as Intel did. So from AMD they have passed the buck to software creators. Recall that Intel processors after the patch by Meltdown lost a good part of their performance, which is why AMD would not be willing to reduce the performance of its CPUs with a patch in the form of a new microcode for its control unit.