Timeline for Are there any existing JTAG (hardware debugging) based malware detection systems, and if not, why?
Current License: CC BY-SA 4.0
8 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 24, 2021 at 10:55 | comment | added | J.Todd | @forest interesting, so a whole new protocol and system would be needed. maybe worth it | |
| Jun 24, 2021 at 0:22 | comment | added | forest | I'm skeptical that a modern Intel CPU in probe mode will be able to run JTAG at any useful speeds. I don't believe the bottleneck is the ITP/XDP system but rather the fact that every instruction has to go through a slow path. | |
| Jun 23, 2021 at 16:19 | comment | added | J.Todd | Then again, I'm forgetting that fetch-decode execute is a 3 clock cycle process, so we probably only need to read each fetch, so likely only ~1GB/s of bandwidth is needed per physical core on a modern CPU to make it possible. | |
| Jun 23, 2021 at 15:55 | comment | added | J.Todd | @forest Maybe I was a bit unclear introducing that idea about needing only 3GBytes of bandwidth instead of 24. 24 would be observing a 64 bit write operation each clock cycle, but instead we only really need to observe the Current Instruction Register or Instruction pipeline which for should equate to 1 byte of data per clock cycle. The ability to read and write to those registers at 3GB/s via some extended version of XDP would create the ultimate security monitoring capability. | |
| Jun 23, 2021 at 15:40 | comment | added | J.Todd | (2/2) I realized we don't need to read a modern CPU's potential of writing 64 bits per op, each instruction itself, although variable, will average 1-2 bytes, so we need probably just over 3 Gbytes/s, half the bandwidth of DDR3. I'm not a computer engineer, so it's hard for me to figure out how hard it would be to add busses with that much capacity connecting each physical core to a JTAG port. But Hyperthreading already uses a second set of registers for each physical core and that's provenly insecure, maybe that infrastructure could be repurposed. | |
| Jun 23, 2021 at 15:32 | comment | added | J.Todd | @forest However I found that Intel implements JTAG over a dual bus system (XDP) that allows one bus to bypass the slower components and operate at a higher frequency tied into the cores and supports multiplexing. Still too slow, but it demonstrates that if the security industry saw value in such a capability, (and I would argue there is value, specifically for customers willing to pay for the specialized product) it should be feasible to develop a processor with enough bandwidth, probably involving a separate JTAG port for each physical core. You dont need 24 Gbytes/second, either (1/2) | |
| Jun 23, 2021 at 0:25 | comment | added | forest | That's totally correct. You can, however, use JTAG to analyze malware with OpenOCD and GDB, but that's done manually and cannot be done by automated systems for the reason you point out. | |
| Jun 11, 2021 at 9:05 | history | answered | J.Todd | CC BY-SA 4.0 |