Related: a defcon talk about it (DEF CON 26 - Christopher Domas - GOD MODE UNLOCKED Hardware Backdoors in redacted x86) https://www.youtube.com/watch?v=jmTwlEh8L7g

Website collecting info on thin clients, which many are VIA, if anyone gets interested in exploring it from a recycled unit: https://www.parkytowers.me.uk/

EDIT: also https://news.ycombinator.com/item?id=17727140 - Christopher Domas: Hardware Backdoors in X86 CPUs

Now seeing the whole context, i feel incredibly betrayed - This was not a backdoor, but behavior documented in the datasheet. I didn't realize this 3 years ago! If this was academics, Domas' work would be plagiarism, with the 2004 datasheet being unquoted prior work: http://datasheets.chipdb.org/VIA/Nehemiah/VIA%20C3%20Nehemia... (Page A-10 in the appendices)

Wasn't his thing about accessing it not finding it, though? We all know Intel CPUs have management engines, running doom on one would be a feat.

The most annoying thing about esoteric wiki articles is missing context. Most of them explain the thing but not HOW or WHY it matters or why it is important.

There doesn't seem to be any context on whether this was an intentional feature, intended to be used by userspace programs, or something entirely undocumented that wasn't intended to see widespread use. What's more, it doesn't dive into why it matters - if the microarchitecture's the same, isn't the only benefit a shorter pipeline; maybe you can skip some of the complex CISC->RISC decoding?

Itanium seems to have, in any case, shown us that exposing the microarchitecture for the sake of performance is an antipattern.

Did you happen to notice how almost every other word in the summary is blue?

I'm sure they did (a gentle reminder that we try and avoid snark on HN -- see the guidelines).

This post intrigues me and piques my curiosity -- it's an interesting fork of the Intel x86 family tree that obviously didn't go anywhere. But the context for the submission is also interesting: does it relate to some emulator work that the submitter is doing, for example? Or is there a potential vulnerability that could be exposed by the existence of these instructions? Or was it purely the discovery of this learning that caused them to want to share it? HN doesn't provide an automatic means to share that context with a link submission, which is a pity. But I for one would love to hear more from the poster.

I think I misunderstood the comment. I was thinking about the article and not about the HN submission of the article.

And to that, I also wonder why many posts were posted when they don't come with any comment.

It seems to me the article is missing one very big piece of information that's mentioned by the linked security research: memory reads/writes in the alternate instruction set are not confined by x86 access protections, but ALTINST can be run by unprivileged code. Is that true? Should the article state it more clearly?

This is documented on Page A-10 of that processor datasheet: http://datasheets.chipdb.org/VIA/Nehemiah/VIA%20C3%20Nehemia...

Which states that while the ALTINST instruction is not privileged, it depends on a certain bit in an MSR which needs to be enabled first, and that's privileged.

Is "ring 0 but confined by access protections" a thing?

Yes: https://en.wikipedia.org/wiki/Supervisor_Mode_Access_Prevent...

I'm surprised something like this wasn't implemented as a deliberate, marketed feature for cross compatibility.

The OS would tag each task or memory page as being, say, an x86-64 or ARM task, and when a task was dispatched, it would be done as a "JSR + change operating mode" instruction. This feels like it would be more permanent than a Rosetta style software bodge that could be taken away in the next point release.

The old NEC V20/30/40/50 CPUs offered something like this-- they powered up as 8086/186 class, but you could bump them in and out of 8080 mode. You'd think it would be easier today with modern micro-op architectures that look mostly the same behind the decoder.

Well, the jump from real mode (16 bit) at boot to protected mode (32 bit) and protected to long mode (64 bit) are all accomplished by flipping some bits in the control registers and doing a “long jump” (a regular jump is implicitly the same segment address/selector, but a long one has an explicit one). Basically, the processor only detects operating mode changes when a long jump is performed. (This allows the OS to set up a process for execution, flip the mode bits if needed, then long jump to the process)

I'm little bit sad that VIA didn't produce new CPUs.

Or even if they make - they can be purchased anymore. I have one Eden 600 or 900MHz CPU on Mini-ITX MB.

There's one recent enterprise chip called CHA.

[0]: https://en.wikichip.org/wiki/centaur/microarchitectures/cha

[1]: https://www.techpowerup.com/263978/via-centaur-cha-ncore-ai-...

I had a via nano at 1200MHz that was just a lovely machine and ran with just a single silent system fan (no CPU fan even)

Same here! Only fan is on PSU but was small and quiet.

They are still licencing IP out (to China specifically IIRC)

But they did. Except it's now called Zhaoxin, and I believe they completely ignore the US and EU markets.

I bet there's a similar mode for all intel's CPUs, which are RISC in essence.

Why would the VIA C3 series from 2001 have supported RISC-V?