Live data from Hacker News

"Intel Packet of Death" not Intel's problem

h-online.com

31–33 of 33 posts

Re: "Intel Packet of Death" not Intel's problem

#31

Earlier quoted context omitted.

Kristian Kielhofner here - While I understand your analogy I don't think it's an accurate one. In fact, with the release of the successor to the 82574 Intel has already implemented some of the things I suggested: http://communities.intel.com/community/wired/blog/2012/10/18... Clearly they have learned from the various EEPROM issues on previous controllers (including the 82574) and implemented (among other things) EEP…

Let me preface this by saying that your epic trouble-shooting effort was really cool. That's what inspires me to pay so much attention to this. If you'll excuse my ignorance, could you identify which points made on the linked page correspond to your suggestions? I can see how signature checking, if there is in fact such a mechanism on the controller, can help ensure that an EEPROM image is a member of a particular fa…

Thanks!

Let me start by saying that I'm not asking for or expecting perfect hardware or software. This does not exist. I'm looking for improvements. Sane? Let's start with "sane-er". I linked to the i210 because it offers exactly what I'm asking for: improvement (as you'd expect in 4+ years of development).

The link for the i210 was an overview for general consumption. The 862 page datasheet is here:

http://www.intel.com/content/dam/www/public/us/en/documents/...

The description of the various memory and configuration spaces starts around page 53. When compared to what's available in the 82574L this is clearly a substantial improvement.

However, as I say in my update, we still don't /really/ know why this issue manifested the way it did. Without knowing the true underlying cause anything I offer is speculation, as are your suppositions. With that it is unknown as to whether or not the improvements in the i210 would have eliminated or even ameliorated this issue.

As far as catching this exception in driver software? Possible, but doubtful. Working with Intel last fall they seemed to dismiss this possibility. Current drivers report a loss of communication with the PHY and the adapter seems to essentially disappear from the PCI bus until a full power cycle.

Neither Intel nor my board vendor reported these findings to me until this story broke last week. I reported this issue to them last fall: both of them claimed to have never seen this issue before (or since).

Meanwhile, as I’ve said before, other people have consistently reproduced this issue with different board manufacturers. We are pursuing a second source but I'm not going to be any more confident with the second source if it has 82574L controllers. I can't be certain it's going to be any different.

Re: "Intel Packet of Death" not Intel's problem

#32

Earlier quoted context omitted.

Let me preface this by saying that your epic trouble-shooting effort was really cool. That's what inspires me to pay so much attention to this. If you'll excuse my ignorance, could you identify which points made on the linked page correspond to your suggestions? I can see how signature checking, if there is in fact such a mechanism on the controller, can help ensure that an EEPROM image is a member of a particular fa…

Thanks! Let me start by saying that I'm not asking for or expecting perfect hardware or software. This does not exist. I'm looking for improvements. Sane? Let's start with "sane-er". I linked to the i210 because it offers exactly what I'm asking for: improvement (as you'd expect in 4+ years of development). The link for the i210 was an overview for general consumption. The 862 page datasheet is here: http://www.intel…

Thanks so much for the detailed response, and good luck in your hunt for better vendors. It seems that it's going to fall to you to test and correct the EEPROM settings. You might want to keep your results to yourself in future; you could probably get some big-money consulting work with other companies forced to use these products. It's so shitty that neither party bothered to respond until you went public with this.

Re: "Intel Packet of Death" not Intel's problem

#33
post #8
post #3

Company from Taipei flashes some Intel equipment, then it appears to function correctly, but can be bricked remotely with a specially crafted incoming packet. Company has US branch that's a government contractor: http://government-contractor.bizdirlib.com/ceo/Synertron_Tec... Charming.

If this were a DoS backdoor, it would've not been that much harder to make it less discoverable. Just use two magic bytes, or three. The chance of false positive are virtually zero and yet you'd still be able to use basic ICMP/ping to trigger it if needed.

A backdoor that bricks the device, but only if it's the first packet received, isn't terribly useful. The more plausible explanation is that it's a bug that was introduced by the actual backdoor that still remains undiscovered.
Post reply on HN