4 ms·

Isn't this partly what Intel wants to do with X86-S? https://www.intel.com/content/www/us/en/developer/articles/technical/envisioning-future-simplified-architec

by tim-- 3y ago

Isn't this partly what Intel wants to do with X86-S? https://www.intel.com/content/www/us/en/developer/articles/technical/envisioning-future-simplified-architecture.html https://www.intel.com/content/www/us/en/developer/articles/t... Stripping away old/unused instructions from the legacy x86 arch. I would assume though that much of the new security vulnerabilities are not coming from these legacy instructions though. Surely they would be battle tested by now?

I_Am_Nous 3y ago
The newest Intel CVE seems tied to some legacy handling of duplicate prefixes, where it usually ignores duplicate prefixes since they were used to pad memory registers sometimes. A newer feature added onto x86 is the underlying problem (FSRM), but it's mishandling those "battle tested" instructions/improperly reading them. So really, it's a combination of things that led to this CVE, and the longer we stay on an old platform the more strange combinations we might find!
- adrian_b 3y ago
  I have looked at the file "icebreak.asm" that is the reproducer for the Intel bug, and it contains a double REX prefix on a movsb instruction. According to all documents that have ever been published by either Intel or AMD for x86-64, it is forbidden to have more than one REX prefix in an instruction. Therefore, the instruction from "icebreak.asm" should have generated an undefined instruction exception. While in this case the behavior of the bug is extreme, by completely crashing the computer, if there are other Intel or AMD CPUs which just ignore the duplicated REX prefix, without generating the undefined instruction exception, according to their CPU architecture documentation, that is already an extremely severe bug and such lax implementations are very likely to lead to more damaging bugs, like this.
adrian_b 3y ago
Actually this particular bug comes directly from the obsolete instruction "invd", which was introduced in Intel 80486, in 1989. This instruction should have been disabled when virtualization is used and when it is desired that the virtual machines must be protected even against the hypervisor, not only against each other. Even better would be if this instruction would be removed completely. Because it is a privileged instruction, its removal would not affect any user applications. This is one of the very rare cases when Intel has done the right thing (disabling INVD when it could be used by an attacker), while AMD has not thought about it. Fortunately, it seems that AMD can fix this oversight with a microcode update.

by tim-- 3y ago

I_Am_Nous 3y ago

The newest Intel CVE seems tied to some legacy handling of duplicate prefixes, where it usually ignores duplicate prefixes since they were used to pad memory registers sometimes. A newer feature added onto x86 is the underlying problem (FSRM), but it's mishandling those "battle tested" instructions/improperly reading them. So really, it's a combination of things that led to this CVE, and the longer we stay on an old platform the more strange combinations we might find!

adrian_b 3y ago
I have looked at the file "icebreak.asm" that is the reproducer for the Intel bug, and it contains a double REX prefix on a movsb instruction. According to all documents that have ever been published by either Intel or AMD for x86-64, it is forbidden to have more than one REX prefix in an instruction. Therefore, the instruction from "icebreak.asm" should have generated an undefined instruction exception. While in this case the behavior of the bug is extreme, by completely crashing the computer, if there are other Intel or AMD CPUs which just ignore the duplicated REX prefix, without generating the undefined instruction exception, according to their CPU architecture documentation, that is already an extremely severe bug and such lax implementations are very likely to lead to more damaging bugs, like this.

adrian_b 3y ago

Actually this particular bug comes directly from the obsolete instruction "invd", which was introduced in Intel 80486, in 1989. This instruction should have been disabled when virtualization is used and when it is desired that the virtual machines must be protected even against the hypervisor, not only against each other. Even better would be if this instruction would be removed completely. Because it is a privileged instruction, its removal would not affect any user applications. This is one of the very rare cases when Intel has done the right thing (disabling INVD when it could be used by an attacker), while AMD has not thought about it. Fortunately, it seems that AMD can fix this oversight with a microcode update.