6 ms·

Alternate Instruction Set

76 points by lelf 5y ago

mobilio 5y ago
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.
- aidenn0 5y ago
  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)
  - mobilio 5y ago
    Same here! Only fan is on PSU but was small and quiet.
- jagger27 5y ago
  There's one recent enterprise chip called CHA. [0]: https://en.wikichip.org/wiki/centaur/microarchitectures/cha https://en.wikichip.org/wiki/centaur/microarchitectures/cha [1]: https://www.techpowerup.com/263978/via-centaur-cha-ncore-ai-cpu-pictured-a-socketed-lga-package https://www.techpowerup.com/263978/via-centaur-cha-ncore-ai-...
- mhh__ 5y ago
  They are still licencing IP out (to China specifically IIRC)
- trasz 5y ago
  But they did. Except it's now called Zhaoxin, and I believe they completely ignore the US and EU markets.
ape4 5y ago
Too bad its not RISC-V
- lloydatkinson 5y ago
  Why would the VIA C3 series from 2001 have supported RISC-V?
throayobviousl 5y ago
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.
- Brian_K_White 5y ago
  Did you happen to notice how almost every other word in the summary is blue?
  - timsneath 5y ago
    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.
    - Brian_K_White 5y ago
      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.
- don-code 5y ago
  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.
ExcavateGrandMa 5y ago
excellent, thanks; btw u tracking me lately? :Ð
corebuffer 5y ago
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 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/ https://www.parkytowers.me.uk/ EDIT: also https://news.ycombinator.com/item?id=17727140 https://news.ycombinator.com/item?id=17727140 - Christopher Domas: Hardware Backdoors in X86 CPUs
- blueflow 5y ago
  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%20Nehemiah%20Datasheet%20R113.pdf http://datasheets.chipdb.org/VIA/Nehemiah/VIA%20C3%20Nehemia... (Page A-10 in the appendices)
  - mhh__ 5y ago
    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.
geofft 5y ago
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?
- detaro 5y ago
  Is "ring 0 but confined by access protections" a thing?
  - geofft 5y ago
    Yes: https://en.wikipedia.org/wiki/Supervisor_Mode_Access_Prevention https://en.wikipedia.org/wiki/Supervisor_Mode_Access_Prevent...
- blueflow 5y ago
  This is documented on Page A-10 of that processor datasheet: http://datasheets.chipdb.org/VIA/Nehemiah/VIA%20C3%20Nehemiah%20Datasheet%20R113.pdf http://datasheets.chipdb.org/VIA/Nehemiah/VIA%20C3%20Nehemia...
  - trasz 5y ago
    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.
ruslan 5y ago
I bet there's a similar mode for all intel's CPUs, which are RISC in essence.
hakfoo 5y ago
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.
- colejohnson66 5y ago
  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)

76 points by lelf 5y ago

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.

aidenn0 5y ago
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)
- mobilio 5y ago
  Same here! Only fan is on PSU but was small and quiet.
jagger27 5y ago
There's one recent enterprise chip called CHA. [0]: https://en.wikichip.org/wiki/centaur/microarchitectures/cha https://en.wikichip.org/wiki/centaur/microarchitectures/cha [1]: https://www.techpowerup.com/263978/via-centaur-cha-ncore-ai-cpu-pictured-a-socketed-lga-package https://www.techpowerup.com/263978/via-centaur-cha-ncore-ai-...
mhh__ 5y ago
They are still licencing IP out (to China specifically IIRC)
trasz 5y ago
But they did. Except it's now called Zhaoxin, and I believe they completely ignore the US and EU markets.

ape4 5y ago

Too bad its not RISC-V

lloydatkinson 5y ago
Why would the VIA C3 series from 2001 have supported RISC-V?

throayobviousl 5y ago

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.

Brian_K_White 5y ago
Did you happen to notice how almost every other word in the summary is blue?
- timsneath 5y ago
  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.
  - Brian_K_White 5y ago
    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.
don-code 5y ago
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.

ExcavateGrandMa 5y ago

excellent, thanks; btw u tracking me lately? :Ð

corebuffer 5y ago

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 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/ https://www.parkytowers.me.uk/ EDIT: also https://news.ycombinator.com/item?id=17727140 https://news.ycombinator.com/item?id=17727140 - Christopher Domas: Hardware Backdoors in X86 CPUs

blueflow 5y ago
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%20Nehemiah%20Datasheet%20R113.pdf http://datasheets.chipdb.org/VIA/Nehemiah/VIA%20C3%20Nehemia... (Page A-10 in the appendices)
- mhh__ 5y ago
  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.

geofft 5y ago

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?

detaro 5y ago
Is "ring 0 but confined by access protections" a thing?
- geofft 5y ago
  Yes: https://en.wikipedia.org/wiki/Supervisor_Mode_Access_Prevention https://en.wikipedia.org/wiki/Supervisor_Mode_Access_Prevent...
blueflow 5y ago
This is documented on Page A-10 of that processor datasheet: http://datasheets.chipdb.org/VIA/Nehemiah/VIA%20C3%20Nehemiah%20Datasheet%20R113.pdf http://datasheets.chipdb.org/VIA/Nehemiah/VIA%20C3%20Nehemia...
- trasz 5y ago
  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.

ruslan 5y ago

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

hakfoo 5y ago

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.

colejohnson66 5y ago
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)