[HN Gopher] Alternate Instruction Set
       ___________________________________________________________________
        
       Alternate Instruction Set
        
       Author : lelf
       Score  : 68 points
       Date   : 2021-05-30 17:26 UTC (1 days ago)
        
 (HTM) web link (en.wikipedia.org)
 (TXT) w3m dump (en.wikipedia.org)
        
       | throayobviousl wrote:
       | 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 wrote:
         | Did you happen to notice how almost every other word in the
         | summary is blue?
        
           | timsneath wrote:
           | 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.
        
         | don-code wrote:
         | 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.
        
       | mobilio wrote:
       | 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 wrote:
         | 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 wrote:
           | Same here! Only fan is on PSU but was small and quiet.
        
         | jagger27 wrote:
         | 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-...
        
         | mhh__ wrote:
         | They are still licencing IP out (to China specifically IIRC)
        
         | trasz wrote:
         | But they did. Except it's now called Zhaoxin, and I believe
         | they completely ignore the US and EU markets.
        
       | corebuffer wrote:
       | 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
        
         | blueflow wrote:
         | 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)
        
           | mhh__ wrote:
           | 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 wrote:
       | 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?
        
         | blueflow wrote:
         | This is documented on Page A-10 of that processor datasheet:
         | http://datasheets.chipdb.org/VIA/Nehemiah/VIA%20C3%20Nehemia...
        
           | trasz wrote:
           | 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.
        
         | detaro wrote:
         | Is "ring 0 but confined by access protections" a thing?
        
           | geofft wrote:
           | Yes: https://en.wikipedia.org/wiki/Supervisor_Mode_Access_Pre
           | vent...
        
       | ExcavateGrandMa wrote:
       | excellent, thanks; btw u tracking me lately? :D
        
       | ape4 wrote:
       | Too bad its not RISC-V
        
         | lloydatkinson wrote:
         | Why would the VIA C3 series from 2001 have supported RISC-V?
        
       ___________________________________________________________________
       (page generated 2021-05-31 23:01 UTC)