| 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. |