You only have to watch the first 3 mins 13 seconds of this talk to see why the answer is "Just Don't Do It!"
In this post, dated 15th October 2014, I explained the problem, and described a solution to it. This is still something I would like to do, if I could get the werewithal to work again, one day.
After posting that, and prodding around for feedback, I got only one intelligent response, which was Vaughan Pratt asking me what I thought "full disclosure" of hardware and firmware back-doors would mean in practice. Here is my reply.
In this post, dated 15th October 2014, I explained the problem, and described a solution to it. This is still something I would like to do, if I could get the werewithal to work again, one day.
- Note at 17 mins 51 secs, the assumption that the GCR is unique is not justified, as I explain in detail in the aforementioned post. In general, redundancy in the instruction encoding can be used as a covert channel to unlock further levels of hidden functionality. This is relevant to mitigations, at 48 mins 24 secs. You need to know all the possible ways to set the GMB, to know how to lock it down.
- At 21 mins 58 secs, it might be possible to use a fairly straightforward genetic search algorithm to choose stable sets of bits that can be toggled without crashing the system, then run sandsifter after toggling all of the bits in the set. Then you could use some kind of binary chop to hone down the sets to those which yield new instructions. Doing this, you may discover more hidden functionality such as "sub options" enabling more instructions in certain modes.
- At 32 mins 30 secs, a similar genetic search ought to speed up the guessing of instruction opcodes here too.
- At 33 mins 5 secs, this expanded test rig could implement the genetic search in parallel.
- At 49 mins "Backdoors do exist in hardware, but we can find them, using the right techniques." This statement is unjustified by anything the speaker has said in this talk so far. It is also false! This was established by Karger and Schell in http://seclab.cs.ucdavis.edu/projects/history/papers/karg74.pdf See "Teletype string trigger trapdoors". In particular, the following email of mine went to John Harrison at Intel, so at least one person at Intel ought to have known about this!
- 48 mins 43 secs. This guy sounds here just like someone paid by Intel to put out smoke in a desperate attempt to divert a slew of lawsuits that are going to result in Intel filing for bankruptcy!
After posting that, and prodding around for feedback, I got only one intelligent response, which was Vaughan Pratt asking me what I thought "full disclosure" of hardware and firmware back-doors would mean in practice. Here is my reply.
So that reply, and the notes above, show one possible reason why I cannot earn enough, as a security consultant, to pay for my food.
No comments:
Post a Comment