Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

An in-depth security review of the Intel Management Engine

security-center.intel.com

Post reply on HN
Print view View original

131–140 of 192 posts

Re: An in-depth security review of the Intel Management Engine

#131

Post by mrsteveman1 »

0culus wrote: post #104

How does this affect Apple products? I've looked around for discussion of Intel ME with regards to Apple and the silence out there is deafening. [edit] I guess I also want to know is, does Apple provide Intel firmware patches bundled with their own software update?

I suspect they'll be patching this one, but I don't know if they have updated the ME firmware in the past.

However, Intel's own platform tools (MEInfo and MEManuf running in a UEFI shell) can't even communicate with the ME on my 2015 Macbook Pro, so I would be quite interested to know what exactly they have done differently with regard to configuring the platform.

People have been archiving every version of the ME firmware for each chipset, and it would appear there are some versions that may be specific to Apple hardware. I'm not sure what is different, if anything, but you can see (and download) the particular firmware versions here: https://www.win-raid.com/t596f39-Intel-Management-Engine-Dri...

Re: An in-depth security review of the Intel Management Engine

#132

Post by beefhash »

computator wrote: post #116

Don't rush to apply the Intel ME patch! Several HN users here (beefhash, jlgaddis, joe_the_user) have raised the possibility that applying the patch might make it impossible to get rid of the Intel ME entirely. If you don't apply the patch, someone may come up with a nice new exploit (using the security bugs) to completely remove the Intel ME. If you do apply the patch, it might close off possible exploits and you'll…

While we're on the topic -- is there some IRC channel or something dedicated to Intel ME research?

Re: An in-depth security review of the Intel Management Engine

#133

Post by citrin_ru »

arca_vorago wrote: post #121

So when do I start hearing all the BSD/MIT promoters apologize for allowing this normalization of tivoization and admitting RMS was right all along? Oops, that potentially might interfere with profits, never mind, as you were, keep trying the same ol shit.

Cost of licensing closed source or developing own OS for ME is not prohibitive for Intel. No way GPL could prevented creating of Intel ME.

Re: An in-depth security review of the Intel Management Engine

#134

Post by arca_vorago »

citrin_ru wrote: post #133
arca_vorago wrote: post #121

So when do I start hearing all the BSD/MIT promoters apologize for allowing this normalization of tivoization and admitting RMS was right all along? Oops, that potentially might interfere with profits, never mind, as you were, keep trying the same ol shit.

Cost of licensing closed source or developing own OS for ME is not prohibitive for Intel. No way GPL could prevented creating of Intel ME.

Its the attitude that closed source is OK that is the problem.

Re: An in-depth security review of the Intel Management Engine

#136

Post by vbezhenar »

throwaway613834 wrote: post #108
derefr wrote: post #96

Earlier quoted context omitted.

> or if they allowed complete disabling via motherboard jumper That wouldn't really work; the ME is essentially "the CPU" of the Platform Controller Hub. Disabling it would be disabling your computer (e.g. your IOMMU, your DRAM refresh, your ACPI command routing, etc.) All the stuff that used to be done "manually" by the CPU itself back in the 8086 days—using configured IRQs and PITs and whatever else—is done autonom…

>> or if they allowed complete disabling via motherboard jumper > That wouldn't really work; the ME is essentially "the CPU" of the Platform Controller Hub. Disabling it would be disabling your computer (e.g. your IOMMU, your DRAM refresh, your ACPI command routing, etc.) Then how does Intel disable it for governmental customers (high-assurance)?

They don't disable it completely. Computer can't boot and work without ME.

Re: An in-depth security review of the Intel Management Engine

#137

Post by exikyut »

beefhash wrote: post #132
computator wrote: post #116

Don't rush to apply the Intel ME patch! Several HN users here (beefhash, jlgaddis, joe_the_user) have raised the possibility that applying the patch might make it impossible to get rid of the Intel ME entirely. If you don't apply the patch, someone may come up with a nice new exploit (using the security bugs) to completely remove the Intel ME. If you do apply the patch, it might close off possible exploits and you'll…

While we're on the topic -- is there some IRC channel or something dedicated to Intel ME research?

Good question. I'm not aware of any; I say make one.

The question is what the best IRC server would be to use; considerations include reputation and "unpopularity", ie certain overly busy networks may scare some people away.

There's also the possibility of using Discord.

The main issue is encryption; most won't have any opinions on the subject, but more vocal types who may be useful to have on board may insist on specific forms of security in order to participate.

Just my 2c

Re: An in-depth security review of the Intel Management Engine

#138

Post by nullc »

beefhash wrote: post #132
computator wrote: post #116

Don't rush to apply the Intel ME patch! Several HN users here (beefhash, jlgaddis, joe_the_user) have raised the possibility that applying the patch might make it impossible to get rid of the Intel ME entirely. If you don't apply the patch, someone may come up with a nice new exploit (using the security bugs) to completely remove the Intel ME. If you do apply the patch, it might close off possible exploits and you'll…

While we're on the topic -- is there some IRC channel or something dedicated to Intel ME research?

Well I just created ##intelme on freenode. Though, I'm just a nobody whos managed to get his laptop me_cleanered.

Feel free to join.

Re: An in-depth security review of the Intel Management Engine

#139

Post by TD-Linux »

rphlx wrote: post #114
throwaway613834 wrote: post #108

Earlier quoted context omitted.

>> or if they allowed complete disabling via motherboard jumper > That wouldn't really work; the ME is essentially "the CPU" of the Platform Controller Hub. Disabling it would be disabling your computer (e.g. your IOMMU, your DRAM refresh, your ACPI command routing, etc.) Then how does Intel disable it for governmental customers (high-assurance)?

The GP is simply wrong on many/most of its technical claims. ACPI implementations were common for 4+ years before the ME existed. The ME is not involved in DRAM refresh or initialization at all (other than waiting for it to complete..). DRAM refresh is hardened into the IMC, and the initialization SW runs on the x86_64 cores - typically it's a UEFI binary blob provided by Intel. Once the OS is running, it manages the…

This is backed up by older systems working fine with the ME firmware completely removed, and on newer systems, for 30 minutes before a watchdog triggers: https://github.com/corna/me_cleaner

Re: An in-depth security review of the Intel Management Engine

#140

Post by TD-Linux »

zkms wrote: post #118
rphlx wrote: post #114

Earlier quoted context omitted.

The GP is simply wrong on many/most of its technical claims. ACPI implementations were common for 4+ years before the ME existed. The ME is not involved in DRAM refresh or initialization at all (other than waiting for it to complete..). DRAM refresh is hardened into the IMC, and the initialization SW runs on the x86_64 cores - typically it's a UEFI binary blob provided by Intel. Once the OS is running, it manages the…

> The GP is simply wrong on many/most of its technical claims I concur. Also regarding: ACPI, there often is an auxiliary microcontroller used to do power management and keyboard interfacing called "embedded controller" (sometimes there's also a mysterious ASIC, part numbers for them include Rohm BU77700KVT Toshiba TB62D515FG,TB62501F) that lives on some SMBus and with which the ACPI implementation, running on the ma…

On newer Thinkpads, the firmware for the EC is on the same SPI Flash as the ME firmware, but on a different partition. The EC is an entirely separate chip (labeled ThinkEngine) and by virtue of being only on SMBus is a lot less dangerous.
Post reply on HN