News for hackers. Stuff that matters.
Re:Intel Security True Key by temptel on Sunday December 04, 2016 @05:33PM (#13102143)
You've been unable to find that information because no such "functionality" exists. Microcode just patches bugs or configuration details of the CPU; it doesn't "phone home".
Re:Intel Security True Key by akerl_ on Sunday December 04, 2016 @05:36PM (#13102157)
That was my initial understanding, but I figured I'd give the parent commenter the benefit of the doubt in case my understanding was flawed.

Some more searching seems to lead back to where I started: the microcode itself isn't phoning home, the only phoning "home" that occurs is the normal process of "when you pull down an update for something, it requires phoning to the repository holding the updates".

Re:Intel Security True Key by benchaney on Sunday December 04, 2016 @06:09PM (#13102268)
How could it possibly patch bugs without phoning home? Are you claiming that it is self modifying code?
Re:Intel Security True Key by akerl_ on Sunday December 04, 2016 @06:39PM (#13102380)
I wouldn't consider "running an update where it pulls new code" to be "phoning home", any more than my car is "phoning home" when I drive it to the dealership for repairs.

The implication the comment I was replying to gave was that the device sent unexpected network traffic back to Intel HQ, with the connotation that it was doing so to leak information about my system.

Re:Intel Security True Key by benchaney on Sunday December 04, 2016 @06:43PM (#13102403)
"Running an update where it pulls new code" is definitely an example of phoning home, and it opens the door to all sorts of vulnerabilities, such as the one featured in the Apple vs the FBI case.
Re:Intel Security True Key by twr on Sunday December 04, 2016 @08:14PM (#13102741)
Intel microcode updates on Linux are provided through regular distribution repositories. There is no phoning home feature.
Re:Intel Security True Key by benchaney on Sunday December 04, 2016 @08:40PM (#13102840)
Do they get updated when you run the package manager, or do they update automatically?
Re:Intel Security True Key by twr on Sunday December 04, 2016 @09:51PM (#13103062)
Binary packaging systems download microcode.dat (a text blob containing microcode) from Intel during the build process. Microcode.dat gets converted into an initramfs image that supplies the new microcode early in the system boot. Users download the built binary package, which then modifies the boot parameters of their system.

So normally only the build servers contact Intel. Source-based distributions may. But even then the source files are verified with cryptographic hashes (which are in turn signed by the maintainers' private keys).

Edit: I may have misread your question. I thought you were asking by implication if the microcode blob is pulled after the install. If not, then: No. Updates happen when the package manager decides.

https://www.kernel.org/doc/Documentation/x86/early-microcode...

https://gitlab.com/iucode-tool/iucode-tool

https://downloadcenter.intel.com/download/26400/Linux-Proces...

Re:Intel Security True Key by akerl_ on Sunday December 04, 2016 @09:01PM (#13102915)
Either via the package manager or via the user manually downloading and loading the microcode update of their choosing. For example: http://askubuntu.com/questions/545925/how-to-update-intel-mi...
Re:Intel Security True Key by jpalomaki on Monday December 05, 2016 @06:06AM (#13104691)
A more subtle way to communicate with the mother ship would be to ship an update that makes the CPU leak some desired information. For example change how some specific cryptographic operation works under certain conditions to make it possible for eavesdropper to break the encryption. Or just make some funny things with memory and make certain information available to be retrieved via web browser when user visits malicious page.
Re:Intel Security True Key by micheljones on Sunday December 04, 2016 @05:36PM (#13102159)
ME does have ability to do that, tho.
Re:Intel Security True Key by comboy on Sunday December 04, 2016 @05:46PM (#13102188)
Do you think you could fit drivers for all common ethernet/wifi cards in there and proper TCP/IP implementation? It's below assembly abstraction level.
Re:Intel Security True Key by Sephr on Sunday December 04, 2016 @08:20PM (#13102761)
Intel ME has independent NIC access and usually cannot be disabled by the user.

It has only been six days since it has become possible to neutralize the ME firmware for Sandy Bridge and Ivy Bridge[1].

[1]: https://news.ycombinator.com/item?id=13056997

Re:Intel Security True Key by moppl on Sunday December 04, 2016 @05:57PM (#13102224)
The ME is basically an independent universal computer in its own right, it comes with its own clock, RAM, CPU etc...

It is like a Matryoshka doll sitting inside the Intel CPU of your computer. Therefore, yes, it can contain all of that. For further details see my other two posts.

Re:Intel Security True Key by comboy on Sunday December 04, 2016 @06:35PM (#13102356)
Sorry I was just thinking about microcodes and you are talking about ME. Scary stuff indeed[1]

1. https://en.wikipedia.org/wiki/Intel_Active_Management_Techno...

Re:Intel Security True Key by imtringued on Monday December 05, 2016 @02:08AM (#13103859)
How else would you implement remote server management that works even when the hardware is shut down (put still connected to power) if not with a seperate CPU that has access to the NIC?
Re:Intel Security True Key by akerl_ on Sunday December 04, 2016 @05:43PM (#13102178)
Just like IPMI, or any other standard for allowing hardware-level admin of a system.
Re:Intel Security True Key by micheljones on Monday December 05, 2016 @03:57AM (#13104208)
By using the word 'standard' you're trying to legitimize something that's fully encrypted, impossible to code-audit and fully under control of Intel, while pretending to be your property and controlled by you.

So yes, it's a standard. I believe there was also a standard on how to tie a noose for hanging a human, but that didn't mean much to the one getting hanged.