Hacker News Reader

Comment by wmf | Hacker News Reader

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.

View on HN

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:

http://datasheets.chipdb.org/VIA/Nehemiah/VIA%20C3%20Nehemia...

(Page 82, "Alternate Instruction Execution")

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...

https://spth.virii.lu/29a7/Articles/29A-7.029.txt

It's not just the C3 that has this feature, if you Google "ALTINST" you'll find more info.

Ah, this kind of deflates things a bit, heh. But then concrete knowledge is better than hype, so this is still interesting.

But the fact that you can twiddle kernel memory from userspace is still fun...

I still wonder why entering debug mode got enabled on some models, but not others. 11th-hour release-to-fab glitch? :/

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.

[1] https://github.com/xoreaxeaxeax/sandsifter

"It's just access to the internal core"

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.

This is a _textbook_ definition of a backdoor.

> 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 a _textbook_ definition of a backdoor.

No.

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.

How is it not a backdoor? Just because it's unintended or due to a very complex reason doesn't mean it's not one.

Not every security vulnerability is a backdoor. (The Intel ME isn't a backdoor either.)

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.

Well-funded espionage organizations can exploit almost everything, so almost everything is a backdoor? Is that a useful definition?

"Thieves can break windows so there's no need to lock your doors". Fallacy.

What is a backdoor? A set of secret instructions that lets you get control or access over target machine. Exactly what this is. Re-read the README.

Well, if it's a documented feature, I'd call it that. You don't call "single user mode" a backdoor.

Granted, you can disable single user mode.

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.

According to the datasheet, this is by design:

"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.

Couldn't resist:

https://www.youtube.com/watch?v=ahcVp8vIicI&t=20s

Not a backdoor; more accurately described as "lack of a door".

Waits for Chris Domas to write an LLVM backend for the internal RISC target so we can get 1337 performance out of our C3's.

Reply on news.ycombinator.com