VIA/Centaur C3 processors are internally RISC and the front end converts x86 instructions into RISC instructions that the processor executes. People used to ask "can I generate native RISC code?" and Centaur always said no, but you know they must have debugging functionality to do that.
And now someone has discovered that sometimes you can enter debug mode from ring 3 and they're calling it a backdoor.
This. When I read the article I instantly recognised this from some datasheet-browsing I did many years ago. It's not a "coprocessor", it's not a backdoor, it's just access to the internal core. It's even documented in the datasheet itself:
Edit: Now it's all coming back to me. I was exploring the 0F opcode space and came upon 0F 3F, which happens to be the "enter alternate execution mode" instruction when it's enabled. There are a lot of other interesting results if you Google "0F 3F", although I remember them being a lot more relevant when I originally discovered this...
While it is (a bit disappointingly) a known instruction, it seems that Domas has came up with this by his own (via sandsifter [1]). Also, it is really unexpected that there is a documented userland instruction that goes to ring 0 anyway, so it is a "documented" "backdoor". In any case I still think that this study is interesting, mainly because it shows that we can inspect such instructions seemingly out of nowhere.
For which the instruction set is not documented.
For which the x86 access instruction ("bound eax") is not documented.
For which the capabilities are not documented.
From which you can circumvent all of the processor's security checks.
> For which the instruction set is not documented.
Why does it matter?
This alternate instruction set is intended for testing, debug, and special application usage. Accordingly, it is not documented for general usage. If you have a justified need for access to these instructions, contact your VIA representative.
> For which the x86 access instruction ("bound eax") is not documented.
The instruction is documented to be LEA (which I presume is correct for this particular processor) and:
While all VIA C3 processor processors contain this alternate instruction feature, the invocation details (e.g., the 0x8D8400 “prefix”) may be different between processors. Check the appropriate processor data sheet for details.
> For which the capabilities are not documented.
It's documented that you can do pretty much anything:
For example, in the alternate instruction set, privileged functions can be used from any protection level, memory descriptor checking can be bypassed, and many x86 exceptions such as alignment check can be bypassed.
This is an irritating comment, I don't understand some people's urge to disparage others' research even at the expense of rationality.
Even modern Intel and AMD processors are "RISC" under the hood - they decompose CISC x86 instructions into RISC micro-ops, this isn't a VIA phenomenon. But they DON'T open up access to their microcode to some arbitrary user letting you circumvent ring protections to access the kernel from ring 3. If they did that would be a - wait for it - backdoor.
"The mechanism for initiating execution of this alternate set of instructions is as follows:
1. Set the FCR ALTINST bit to 1 using WRMSR instruction (this is a privileged instruction). This
should be done using a read-modify-write sequence to preserve the values of other FCR bits.
2. The ALTINST bit enables execution of a new x86 jump instruction that starts execution of alternate
instructions. This new jump instruction can be executed from any privilege level at any time
that ALTINST is 1."
So to turn on the ability to execute ring-0 non-x86 instructions from ring 3, requires an initial privileged instruction. I believe (from other commenters) that the issue arises because some of the cpu's left the fab with ALTINST set to 1 by default. Meaning, no privileged instruction required. Clearly, that's a fuck-up somewhere.
I'd call it a glaring design flaw. And if very, very few users might notice that documentation, then I'd call it a backdoor hidden in plain sight. For all intents and purposes it really is a backdoor.
You're being either overly generous to Intel or you're underestimating how well funded some of the espionage organization really are. And consider that for decades espionage organizations have been taking advantage of bugs in commercial products. This is so well documented at this point that it's not even worth arguing. Personally I believe this has been going on since the '70's.
Thanks for that little side-bar/rabbit-hole. Fascinating, as is the paper he based it on. I'm itching to get home and try this out - specifically, I'm interested on what the performance might be like.
> I'd love to hear from any alums (danluu?) what the purpose of the coprocessor is.
Absolutely agree there, I can imagine it being ridiculously interesting.
But the truth might also be equal parts boring and scary instead. I mean...
> The backdoor allows ring 3 (userland) code to circumvent processor protections to freely read and write ring 0 (kernel) data. While the backdoor is typically disabled (requiring ring 0 execution to enable it), we have found that it is enabled by default on some systems.
> The core executes these commands (which we call the 'deeply embedded instruction set'), bypassing all memory protections and privilege checks.
> The rosenbridge backdoor is entirely distinct from other publicly known coprocessors on x86 CPUs, such as the Management Engine or Platform Security Processor; it is more deeply embedded than any known coprocessor, having access to not only all of the CPU's memory, but its register file and execution pipeline as well.
This is enough anti-plausible-deniability that I can just sweepingly point everybody in the direction of the big fat (flashing!) elephant in the room and the "..." sitting next to it.
I mean, VIA didn't have as much success as Intel or AMD, but they are a known name. Anything that implements x86 is going to have market penetration to some extent, and VIA achieved success in the industrial and embedded sectors.
If danluu was able to comment here and debunk what I'm saying, I would be both very surprised and even more delighted.
... and embedded in ATMs with a 20 year life span.
Your comment sounds a bit dismissive of the vulnerability with an implication that it would never be a problem. If that was not what you were implying I apologize. It is critical that even "old" chips vulnerabilities be understood so that one can understand the risks. It pains me terribly every time I power up the Agilent signal analyzer in the lab and it boots Windows XP on its Pentium III chip.
I expect that most people miss that ATM manufacturers continue to put security holes in ATMs (https://www.wired.com/2014/11/nashville/) one of the 'fixes' was to make bank access unprivileged. But wait, if I have an escalation vulnerability ...
Sigh. Okay let me rephrase. The thing normally called "privilege escalation", where software that is executing on a machine escapes a sandbox or gets into kernel mode, is not a problem on ATMs.
That page is talking about pressing keys to exploit software flaws in already-privileged software, which is an extremely separate topic.
Privilege escalations come in many shapes and sizes, it is not limited to software escaping a sandbox or to get into kernel mode, it is also explicitly used to refer to users of a system managing to leverage their normal access into a more powerful one.
I don't think minimizing the significance of the exploit should happen in the headline, but saying "x86 CPUs" instead of "Via CPUs" in the headline is very clickbaity.
"Via x86 CPUs" would be perfect. It conveys detailed information to those with detailed knowledge while still being understandable to those less familiar with tertiary cpu manufacturers.
This is absolutely implemented in modern CPUs, as debug or management features. Usually switched off - being able to turn it on from ring 3 would be a massive bug.
> VIA processors are renowned for their low power usage and excellence in embedded designs; we believe that the functionality described was created in good faith as a useful feature for the embedded market, and was unintentionally left enabled on some early generations of the processor.
I could see using a secondary core as a watchdog in an embedded environment-- if something went too wrong, perhaps the secondary CPU can either get some valuable logging data or stuff the system with code designed to restore it to a controllable state.
We should go back to real mode. Imagine all the sudden possibilities. No pesky memory barriers, no protection faults and superb integration of applications of all kind. Application could even share the same memory and the better one wins.
"If nothing is secure, everything is secure" - Lincoln
But seriously: I don't think this "feature" is a real backdoor. It is nonetheless an interesting topic.
I am more concerned about bugs and backdoors in modules like TPM/ME or other even less documented surprises. Wouldn't be the first time that happened and we can only hope, that better people find these type of vulnerability first.
This is still a huge target. I used to be in point of sale engineering, and the majority of the quality terminals the big OEMs(NCR and their sub brands, posiflex, etc) were pushing were running these for a LONG time past when you'd think C3 was "dead". Similar vendors i bumped into were pushing stuff with them in it still when i got out of that industry.
There are a LOT of machines out there which will be run essentially until they break down(and a lot are fanless, and will pretty much last until they can't be kept up to date). You have to remember, a lot of big chains(and banks!) paid for extended XP support and then extended-extended XP in the form of windows POS.
This is a "every terminal in a huge fast food chain gets owned and no one finds out for years" sort of vulnerability. This is the first step to something like the target breach all over again.
>This is a "every terminal in a huge fast food chain gets owned and no one finds out for years" sort of vulnerability. This is the first step to something like the target breach all over again.
Utter nonsense, this bug will not lead to RCE.
You might be able to implement a fancy rootkit with this, but that's all. Advanced rootkit tech is neither necessary nor particularly helpful for these sorts of breaches.
Documented instruction set switch which is just implemented poorly. But the real news here seems to be that the ALTINST is set to 1 by default in some C3 generations.
It really is incredible to see that a third party apparently has discovered a genuine backdoor in a production CPU with completely independent research. If that's within reach for a standalone researcher, what secrets lie in well-funded organizations at the nation level?
Perhaps this will bring further mindshare to the RISC-V approach in the future?
Personally I'd love to see a CISC-V --- the world really doesn't need any more MIPS-lookalikes, and a formal spec of x86 would be extremely useful for everyone from emulator writers to maybe even Intel itself.
That would be nice, but I'm more hopeful in the immediate for openpower to gain widespread usage on the desktop. Google seems to be banking on it for servers, at the very least.
Isn't openpower not actually very open? At least with RISCV we can compete vendors while maintaining a compatible instruction set, I'm not sure how many people are going to produce openpower chips.
In the long term, I think you have a point here. It would be nice to have IBM not being the only producer of, say, the POWER15. In that sense RISC-V is substantially more open than OpenPOWER.
But parent was talking about in the immediate timeframe, and right now (and I predict for the next few years at minimum), if you want free(r) and ballpark performance class with x86, then you're going to have to play with POWER. I don't think ARM is there yet with respect to grunt and some ARM designs have some of the same concerns about creepy dark corners of the processor die. It's why there's a Talos II under my desk.
I wanted one of those, just couldn't justify the price. I've been toying with the idea of running Reactos or Haiku on an FPGA as a cheaper "you own it as much as possible" variant.
This is absolutely insane! With all the recent bugs and features that looks like backdoors I have completely lost faith in x86.
We need simple open ISAs (like RISC-V) and a handfull of trusted organizations that inspect the manufacture processes to protect ourselves from this. A bit like how countries and organizations send people to inspect other countries democratic voting processes, or like how IAEA inspect nuclear stockpiles etc.
I call for:
+ Open source.
+ No creeping featurism.
+ Multiple inspection organizations that watch the process from source code to final chip product.
And now someone has discovered that sometimes you can enter debug mode from ring 3 and they're calling it a backdoor.