[i336_]

Something security-related to keep in mind (TL;DR at end):

Directory state after initial unpack (becomes important in a minute):

  -rwxr-xr-x 1 i336 users 19K May 13 10:43 INTEL-SA-00075-Discovery-Tool
  -rw-r--r-- 1 i336 users 27K May 13 10:57 INTEL-SA-00075-Discovery-Tool.c
  -rwxr-xr-x 1 i336 users 15K May 13 10:44 INTEL-SA-00075-Unprovisioning-Tool
  -rw-r--r-- 1 i336 users 16K May 13 10:42 INTEL-SA-00075-Unprovisioning-Tool.c
  -rw-r--r-- 1 i336 users 187 May 13 10:42 Makefile

Build:

  $ cd INTEL-SA-00075-Discovery-Unprovisioning-Tool-Engineering-Release
  $ make
  gcc -I../../usr/include    INTEL-SA-00075-Discovery-Tool.c   -o INTEL-SA-00075-Discovery-Tool
  strip INTEL-SA-00075-Discovery-Tool INTEL-SA-00075-Unprovisioning-Tool
  $

OK; wipe and do it again:

  $ rm INTEL-SA-00075-Discovery-Tool INTEL-SA-00075-Unprovisioning-Tool
  $ make
  gcc -I../../usr/include    INTEL-SA-00075-Discovery-Tool.c   -o INTEL-SA-00075-Discovery-Tool
  gcc -I../../usr/include    INTEL-SA-00075-Unprovisioning-Tool.c   -o INTEL-SA-00075-Unprovisioning-Tool
  strip INTEL-SA-00075-Discovery-Tool INTEL-SA-00075-Unprovisioning-Tool
  $

Wait - why did the unprovisioning tool only get compiled on the second build?

Because the binary for the unprovisioning tool is two minutes NEWER than the source code, as shown in the directory listing.

The binary for the discovery tool is older than the source (as normal).

Objectively it's 50/50 as to whether this is meaningless noise or something hidden. Of course everything points toward the former, but I thought I'd leave this here just in case.

It's worth noting that an independent security company rapidly found (and announced) the vulnerability after the initial undisclosed CVE. So if it was that easy, this vulnerability has clearly been known about in various circles for a while.

It's also worth noting that the build process strips the binary, which is arguably unnecessary, but is a nice way to explain why there are no debug symbols in the provided binaries.

Again, I trust Intel and can easily talk this away as the inanites of bureaucracy and management and deadlines, but my "hmmm" sense is tingling nonetheless.

[orblivion]

I'm not even sure what you're implying.

EDIT: Is it that we should build it ourselves, and not trust the binaries?

EDIT 2: Well, whatever it is, I moved away the binaries and just built it again myself. It was trivial; just type `make` and it's instantly there. (I guess you need gcc and stuff)

[i336_]

Sorry, I was in a bit of a rush when I made the above comment - you're right, I could have worded it a little more clearly.

I don't have `ls` colorization enabled on this laptop, so I didn't immediately notice the binaries next to the source code; the first thing I noticed was the Makefile. So I just ran "make" to see what would happen.

By the time make was done my eyes had noticed the two different tools - and the fact that only one of them had rebuilt. So I freaked out, probably completely unnecessarily.

Essentially what I was thinking was, why is the unprovisioning tool binary that got copied into the distribution newer than the associated source code? How does that work?

The only scenario I can come up with is that a build server was mounted via NFS to the developer machine that prepared the source code, and the local machine's clock was a bit fast. If gcc was being run on the build server, that would produce an binary older than source.

However that does not explain why only the unprovisioning tool was affected in this way, and not the discovery tool (binaries are supplied for both).

Honestly, I'm probably barking up the wrong tree, and I kind of feel silly for posting the comment in the first place. I just wonder, that's all - it makes sense for the discovery tool to remain untouched, with the mitigation tool (the "off" switch) to be tinkered with (somehow).

As for what I'm implying, the worst-case scenario would be some kind of situation where the supplied binary version of tool "all bit completely" disables AMT, somehow leaving one tiny thing in a state where some later process can silently re-enable everything, or otherwise get access to the system. Maybe. Somehow. I have no idea.