[HN Gopher] Two Hidden Instructions Discovered in Intel CPUs Ena...
       ___________________________________________________________________
        
       Two Hidden Instructions Discovered in Intel CPUs Enable Microcode
       Modification
        
       Author : andrewnicolalde
       Score  : 94 points
       Date   : 2021-06-07 21:19 UTC (1 hours ago)
        
 (HTM) web link (www.infoq.com)
 (TXT) w3m dump (www.infoq.com)
        
       | sabas123 wrote:
       | The article is based on the same tweet as this discussion from 3
       | months ago: https://news.ycombinator.com/item?id=26519693
       | 
       | I also want to state how impressive their work is. These are the
       | true undocumented instruction finders as apposed to sandsifter.
        
       | TacticalCoder wrote:
       | > on the good side of things, getting an Intel CPU to enter the
       | red state is not easy to accomplish. In fact, it should never
       | happen unless there are vulnerabilities in the Intel Management
       | Engine (ME), an almost undocumented subsystem present in all
       | Intel CPUs since 2008 that Intel says is required to provide full
       | performance.
       | 
       | "unless there are vulnerabilities or backdoors in the Intel
       | Management Engine (ME)".
       | 
       | There, fixed it for you.
        
         | unnouinceput wrote:
         | The IME itself is a backdoor in the first place. I remember a
         | story a few years past when a full line of CPU's went out with
         | IME having no password set at all, allowing a field day for
         | hackers even when your computer was shut down but still
         | receiving power on standby. Intel had to recall all of them but
         | only after the news blew in media in the first place. Otherwise
         | I'd suspect Intel would've just let it stay, cause money talks.
        
       | dataflow wrote:
       | > it allows to craft your own persistent microcode patch without
       | external debugger.
       | 
       | These are _persistent_? Meaning they survive reboots? Is it
       | stored in flash memory on the CPU or something? I thought all
       | microcode updates are re-applied on each boot.
        
         | sabas123 wrote:
         | If you would override the default microcode update, which
         | should be doable if you have that level of access, you could
         | call it persistent no?
        
           | dataflow wrote:
           | Not really honestly. I mean, I thought the microcode update
           | is done by the firmware and/or the OS on boot. Assuming
           | that's correct, whether it's performed or not is entirely
           | dictated by those entities... not by anything related to the
           | CPU. It's like saying "I'm moving to New York" just because
           | there's a car that drives you there from New Jersey every
           | day. And if you really want to call that 'persistent', I'm
           | not sure how one might have a _non-persistent_ update in that
           | case?
        
           | tamrix wrote:
           | Microcode updates have to be reapplied each time you restart
           | your system.
        
       | coretx wrote:
       | Clickbait. Only in debug mode.
        
         | [deleted]
        
         | AnimalMuppet wrote:
         | Not quite. Only in "red state", which is a subset of debug
         | mode. So, even more restrictive than what you said.
         | 
         | But I still don't think that makes it clickbait. From the
         | article:
         | 
         | > The three researchers have posted a video demonstrating how
         | to access the two instructions with only root/admin privileges.
         | This requires uploading a custom UEFI to SPI flash and then
         | rebooting the system, which definitely requires having physical
         | access to it.
         | 
         | So, not remote-able (at the moment). But there's enough there
         | that I can't agree with calling it clickbait.
        
           | fouric wrote:
           | Even aside from security vulnerabilities, wouldn't the
           | ability to write your own microcode for Intel CPUs be
           | interesting for many hobbyists?
        
             | quotemstr wrote:
             | Right. Writing custom microcode can be useful for
             | understanding fine details of the CPU's microarchitecture,
             | which in turn is useful for things ranging from low-level
             | optimization to discovering microarchitectural
             | vulnerabilities that _don 't_ require custom microcode to
             | exploit.
        
         | phh wrote:
         | Personally, I didn't understand the title as a security flaw. I
         | simply understood it as a step forward into
         | understanding/documenting the way Intel CPU work. So I don't
         | think it is clickbait.
         | 
         | The only part I'm not clear, is whether it was possible before?
         | The article seem to imply that physical debugging tools (JTAG-
         | like I presume) were already available to do uOP exploration?
        
           | monocasa wrote:
           | Yeah, previously the same team found a JTAG like mechanism
           | that exposed microarchitectural internals like R/W access to
           | microcode storage.
        
           | [deleted]
        
         | arbitrage wrote:
         | clever. thanks for the explanation.
        
         | monocasa wrote:
         | Not quite clickbait. Previously there was no way to experiment
         | with and introspect the changes in any Intel microcode updates.
         | This gives unverified r/w to microcode update RAM, allowing
         | reverse engineering of at least Apollo Lake updates and update
         | mechanisms.
         | 
         | I've been a little wigged out by the post spectre world of
         | encrypted, unknown blobs changing every couple months. I prefer
         | to treat vendors in a "trust in Allah, but tie up your camel"
         | sort of way as much as possible.
        
         | squarefoot wrote:
         | I don't think they need to resort to clickbait articles.
         | 
         | Dmitry Sklyarov is the same guy that 20 years ago was arrested
         | by the FBI for DMCA violations when visiting the US because he,
         | despite being a Russian citizen working for a Russian company
         | (there's no DMCA in Russia), wrote a software that circumvented
         | Adobe e-books copy protection. Had social media been around
         | back then, #freedmitry would have been a trending hashtag like
         | all similarly named sites that spawned shortly after the
         | arrest.
         | 
         | https://en.wikipedia.org/wiki/United_States_v._Elcom_Ltd.
        
       | rasz wrote:
       | In theory this should open possibility to unlock all the market
       | segmentation gated Intel bullshit like ECC, multiplier change
       | overclocking, etc. Maybe even manipulating CPUID.
        
         | mhh__ wrote:
         | Maybe, but that might be risky in the sense that if a chip has
         | completely faulty behaviour at high clock speed (I'm not
         | familiar with how they bin things in practice) they can sell it
         | as a low speed one. Intel like to segment their products, but
         | it's not completely for profit.
        
       | intricatedetail wrote:
       | Why is it legal to sell a device without providing full
       | documentation, incl ME?
        
         | xxpor wrote:
         | You don't need this to do anything with the CPU that was
         | promised when you bought it.
        
           | intricatedetail wrote:
           | What do you mean? What if I want to change the microcode to
           | something I like?
        
             | edoceo wrote:
             | That wasn't a product claim that Intel made. Its like
             | warranty void if opened, no user serviceable parts inside.
             | 
             | There is no legal obligation to sell you an open and fully-
             | documented CPU.
        
         | selimnairb wrote:
         | Can you provide a legal definition of what "full documentation"
         | would be?
        
       | anonymousDan wrote:
       | I wonder are there implications for Intel SGX?
        
       ___________________________________________________________________
       (page generated 2021-06-07 23:00 UTC)