This shows that large companies making closed-source CPUs cannot be trusted. No doubt they would add whatever the government asks them to add.
What can be done to mitigate this? One option would be to buy a large FPGA and flash it with an open-source CPU. Another would be to emulate a CPU, working with encrypted data and commands, so that even if the backdoor in a host CPU tries to overwrite memory, it would only crash the emulated OS. One more option would be to run the code in a Virtual Machine like QEMU which translates the code and prevents issuing unknown instructions.
this is pretty old by now but still very relevant. people dont look at this enough but with rising chip complexities for TPU units etc. and a shift towards poorly documented hardware like NVIDIA gives this problem new fuel.
Domas (and maybe his team or colleagues?) has put out shit tons of very interesting materials over the past years on advanced malware, implants and things like Cantor Dust which are amazing things to dive into.
using his own cpu fuzzer, msr fuzzing techniques etc. he has found, reversed and implemented attacks through hardware bugs and backdoors.
It cant be confirmed if a backdoor is malicious or for debugging but essentially the capabilities gained through them are what is important.
These techniques he shows throughout his videos are not super tricky to replicate and I can recommend people who have interest to dive into it, reproduce things and try to help in this domain to raise awareness and findings.
Another good avenu is:
Defcon 21 - Decapping Chips The Strike Easy Hard Way
People speak about supply chain issues in NPM and Pip etc. but these are much more severe and hard to detect.
Almost no one looks at it.
Most vendors totally ignore it because you cannot sell products against it. (if ud detect it u need to trash the hw so its not handy... for sales...)
So is it apparent that this backdoor was intentionally added by VIA for nefarious purposes? Or is there any other reasonable explanation for its existence?
I was wondering the same, this is an ancient CPU by now, having been introduced in 2001. During development and at the introduction, most people were still running Windows 95/98/ME, which had more serious security issues (like every user essentially being admin). It may just have been a handy (debugging?) feature?
Yes there is a harmless explanation. The VIA C3 is a fairly simple CPU design that cracks x86 instructions into an internal simpler instruction format. Some complex x86 behaviour is normally implemented by lengthy microcode or complex state machines. VIA wanted to make their CPU simpler than Intel and AMD. To do that they exposed this internal instruction set to the BIOS to let it handle hardware initialisation and documented how to lock this feature safely away afterward. Some BIOS authors didn't read/understand the full specification. shrug.
IIRC there are also a few hints they at least considered exposing this alternative instruction set at runtime to get more performance out of the CPU core e.g. more useable registers, more three operand instructions, saturating and packed math for DSP workloads, etc.
This shows that large companies making closed-source CPUs cannot be trusted. No doubt they would add whatever the government asks them to add.
What can be done to mitigate this? One option would be to buy a large FPGA and flash it with an open-source CPU. Another would be to emulate a CPU, working with encrypted data and commands, so that even if the backdoor in a host CPU tries to overwrite memory, it would only crash the emulated OS. One more option would be to run the code in a Virtual Machine like QEMU which translates the code and prevents issuing unknown instructions.
This backdoor only appears on decades-old VIA C3 embedded x86 processors
They should have mentioned that in the first line of the github readme, not burried deep down in the text.
You can find recorded presentations on YouTube: https://youtu.be/_eSAF_qT_FY
this is pretty old by now but still very relevant. people dont look at this enough but with rising chip complexities for TPU units etc. and a shift towards poorly documented hardware like NVIDIA gives this problem new fuel.
Domas (and maybe his team or colleagues?) has put out shit tons of very interesting materials over the past years on advanced malware, implants and things like Cantor Dust which are amazing things to dive into.
using his own cpu fuzzer, msr fuzzing techniques etc. he has found, reversed and implemented attacks through hardware bugs and backdoors.
It cant be confirmed if a backdoor is malicious or for debugging but essentially the capabilities gained through them are what is important.
These techniques he shows throughout his videos are not super tricky to replicate and I can recommend people who have interest to dive into it, reproduce things and try to help in this domain to raise awareness and findings.
Another good avenu is: Defcon 21 - Decapping Chips The Strike Easy Hard Way
People speak about supply chain issues in NPM and Pip etc. but these are much more severe and hard to detect.
Almost no one looks at it. Most vendors totally ignore it because you cannot sell products against it. (if ud detect it u need to trash the hw so its not handy... for sales...)
So is it apparent that this backdoor was intentionally added by VIA for nefarious purposes? Or is there any other reasonable explanation for its existence?
I was wondering the same, this is an ancient CPU by now, having been introduced in 2001. During development and at the introduction, most people were still running Windows 95/98/ME, which had more serious security issues (like every user essentially being admin). It may just have been a handy (debugging?) feature?
Yes there is a harmless explanation. The VIA C3 is a fairly simple CPU design that cracks x86 instructions into an internal simpler instruction format. Some complex x86 behaviour is normally implemented by lengthy microcode or complex state machines. VIA wanted to make their CPU simpler than Intel and AMD. To do that they exposed this internal instruction set to the BIOS to let it handle hardware initialisation and documented how to lock this feature safely away afterward. Some BIOS authors didn't read/understand the full specification. shrug.
IIRC there are also a few hints they at least considered exposing this alternative instruction set at runtime to get more performance out of the CPU core e.g. more useable registers, more three operand instructions, saturating and packed math for DSP workloads, etc.
Interesting codenames: https://en.wikipedia.org/wiki/List_of_VIA_C3_microprocessors