Hacker News Reader

Comment by I_Am_Nous | Hacker News Reader

These things seem to go in pairs, as there is currently a new Intel CVE on the frontpage too. Someone in the Intel thread mentioned that the underlying issue may be x86 having more and more stuff piled on top of it. That's been great for compatibility, but I'm wondering if it might be worth Intel/AMD making an x86 lite that strips everything but the necessary instructions.

View on HN

Isn't this partly what Intel wants to do with X86-S? 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?

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!

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.

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.

This exploit isn't at all related to the Intel CVE, just a coincidence they came out around the same time. And an instruction set that strips everything but the necessary instructions sounds a lot like ARM or RISC-V. No need to re-invent the wheel.

> an instruction set that strips everything but the necessary instructions sounds a lot like ARM

Have you, by any chance, looked into the contemporary ARM instruction set? Just the list of base instructions for A-profile with 1-2 instructions per line takes 14 pages. And then there are SIMD&FP Instructions, SVE Instructions, SME Instructions. Oh, and also M-profile, and Thumb / Thumb-2 instructions encodings, and more.

A small glimpse could be made here: https://developer.arm.com/documentation/ddi0602/2023-09/?lan...

I'm just thinking about Windows. They are trying to do ARM again, but x86/64 is where they have stayed for compatibility reasons. At a certain point old software won't run on new Windows anyway, so it won't need hardware compatibility with older instructions to facilitate that.

Eventually something will have to change, and is it less work for Intel to shift to ARM than to strip x86?

It's patch Tuesday.

This does make sense, since they can schedule CVE announcements.

Wild, innit? When there's a really rather nasty but Intel only bug; there's corresponding AMD bug, with name and website and all that; even if the actual vulnerability is "if you was 0wnz0red already" grade.

The rest of Intel is rotten stumps but the PR department is still a sharp fang.

Reply on news.ycombinator.com