search

ufrisk / pcileech-fpga

FPGA modules used together with the PCILeech Direct Memory Access (DMA) Attack Software
917 stars 205 forks source link

0x55556666 padding in the middle of receiving a TLP? #155

Closed andreiw closed 11 months ago

andreiw commented 11 months ago

I was under the impression the padding could not be seen while receiving a valid TLP, but I am seeing 0x55556666 sequences after the status word (perhaps even after a few DWs are received). Is this expected? How do I differentiate from TLP payloads containing 0x55556666?

A

andreiw commented 11 months ago

More precisely, I was seeing 0x55556666 after reading the status word. I don't actually have proof of seeing 0x55556666 in the middle of a TLP.

ufrisk commented 11 months ago

the format is 1 status dword + 7 data dwords = 1 octa-dword. filler dwords (0x55556666) may appear outside the octa-dwords.

(they may appear inside the octa-dwords as well by chance if the actual data being read contains this byte pattern).

The filler dwords are there to deal with some quirks of the FT601 USB chip when aborting transfers early.

If you have issues with the filler-dwords appearing in the middle of your data-carrying octa-dwords please let me know, but I have not seen this behavior.

Regardless I hope this will clear up things a bit.

andreiw commented 11 months ago

So far I am seeing filler dwords occasionally after the status dword, which I suppose counts as "in the middle of the octa-word".

How to reproduce: generate a steady stream of CfgRd0 traffic from the host to the card.

ufrisk commented 11 months ago

That should never appear inside the octa-dwords. But it may appear "inside" the TLP under some circumstances.

If you spam the device with a lot of CfgRd messages while at the same time have it so that it's forwarded to the USB (i.e. no filter) and you don't drain any data from the USB (or don't do it fast enough) the internal buffers will fill up and new data from the FPGA will be discarded (sometimes in the middle of a TLP packet).