0
\$\begingroup\$

Based on my previous question about JTAG:

Does the JTAG port have enough bandwidth to monitor the state changes of all cores on an x86 machine, or even one at a time?

Answer: No

JTAG is a bit-serial interface that runs at a maximum of 100 Mbits/sec, including all of the overhead bits for the protocol. That's something less than 12.5 Mbytes/sec of actual data. If you want to record 64 bits (8 bytes) @ 3 GHz, that would produce 24 Gbytes/second of data, more than 2000× what the JTAG interface can handle. - Dave Tweed

My thought about this is: Considering the potential security benefits of monitoring with external hardware and even observe rootkit level malware, maybe if the bandwidth upgrade were possible, specialized CPUs / boards might be viable for companies willing to spend big dollars on such a feature. I work in malware analysis and it can't be understated how much of an advantage such a feature would yield to the field of malware detection.

Edit: And since it's not necessary to track 64 bits / cycle (register state changes) but rather just track instructions (you can re-create register state changes from instructions and average instruction length 1-3 bytes), we can cut the requirement down from 24 Gbytes/second of data to 6 Gbytes/second. Not that it really seems to change much.

So from an electrical engineering perspective, could such an upgrade to JTAG's bus bandwidth be viable, or are there design factors that make it a very difficult or perhaps impossible goal?

\$\endgroup\$
4
  • \$\begingroup\$ It would need to be JTAG-over-some-other-interface that has the terabits of bandwidth you need. Besides, exactly for security (and other) reasons, JTAG port is typically removed or disabled so no one can reverse engineer the software or inject malware in or brick the hardware. I mean someone could already walk around with laptop and JTAG adapter and try gaining access to systems. It was bad enough when direct access to system was possible via FireWire ports via DMA attack. \$\endgroup\$
    – Justme
    Commented Jun 11, 2021 at 12:30
  • \$\begingroup\$ @Justme If you're a government, an army of foreign actors showing up and plugging into a server rack in the basements of thousands of different industries overnight isn't really a concern. Developing a way for those industries to effectively fingerprint the evasive, polymorphic toolset brought in by a zero-day used nation-wide to disrupt critical industries and rapidly respond to / block a second wave using the same tools would be a venture perhaps worth billions in R&D. If we can observe the instructions being executed on each core, machine learning might be leveraged to recognize the toolset \$\endgroup\$
    – J.Todd
    Commented Jun 11, 2021 at 13:10
  • \$\begingroup\$ @Justme (2/2) which, a debugger could do, sure, but A) it's visible to the attacker and B) that debugger is going to cost a lot of overhead and with JTAG some processor models allow observation without halting execution making JTAG a potential solution to do that security monitoring without much overhead. \$\endgroup\$
    – J.Todd
    Commented Jun 11, 2021 at 13:13
  • \$\begingroup\$ Note that JTAG has a lot of overhead, making it a very poor choice to try to scale up to this data rate. \$\endgroup\$
    – Ben Voigt
    Commented Jun 11, 2021 at 19:58

1 Answer 1

Reset to default
1
\$\begingroup\$

In the old days, you would have used in in-circuit emulator (ICE) to be able to observe the entire machine state. That's not practical anymore given the speed and width of datapaths vs. the pinouts available.

Instead, systems use a form of built-in logic analyzer / debug trace, equipped with a high-speed link in conjunction with JTAG. MIPS PDTrace, Motorola ONCE, Intel XDP are examples.

More here: https://www.eetimes.com/jtag-101-part-2-a-review-of-on-chip-debug-types/

Maybe your innovation would be some kind of neural net processor trained to detect attack patterns, embedded on the die and observing certain known behaviors, such as branch sequences. In other words, you have an idea of how to detect rootkit attacks if you observed certain things. How would you make this an IP block?

\$\endgroup\$
6
  • \$\begingroup\$ "An interesting implementation feature of the Intel® XDP is the presence of a second TCLK, TCK1.The implantation allows for two scan chains to be run simultaneously through the XDP.Generally speaking the processor(s) will run at a higher clock rate than other components on the board which may be in the scan chain. Having the processor(s) on one scan chain and the other devices on the second will allow for faster through put times on test scans. Because only one of the scan chains is active at any given instance, it is possible to multiplex the remaining signals on the port." interesting indeed \$\endgroup\$
    – J.Todd
    Commented Jun 11, 2021 at 22:12
  • \$\begingroup\$ Wait does that mean we can run a bus at CPU frequencies? As in higher than 100MHz? and multiplex? There's so much I have to study on this subject it seems.... I'm still worried about the overhead mentioned by Ben Voigt in the comments though.. But thank you I'm at least a step closer to understanding what tech exists in this space now \$\endgroup\$
    – J.Todd
    Commented Jun 11, 2021 at 22:16
  • \$\begingroup\$ The bigger picture is that there are solutions out there that instance debug / trace hardware over JTAG that deal with the I/O bottleneck issue by pushing these on onto the chip. That's the solution, not making JTAG faster. Similar approaches are used for chip testing, such as built-in self-test (BIST), which speeds up the chip testing process by delegating high-throughput I/O to on-chip hardware, only using JTAG to control the block. In other words, rethink your problem. \$\endgroup\$
    – hacktastical
    Commented Jun 11, 2021 at 23:15
  • \$\begingroup\$ "rethink your problem" alright, but I'm looking for the right entry-point to research the tech. I'm diving 5 pages deep into search results for "Intel XDP" and finding very very little documentation. I've found the $1000+ connector required to access the port. I've found there are some alternatives to accessing XPD aside from the port, but possibly at lower speeds. \$\endgroup\$
    – J.Todd
    Commented Jun 12, 2021 at 3:04
  • \$\begingroup\$ In your opinion am I on a wild goose chase here or could extended research potentially reveal a way to record every instruction executed on an intel CPU via some form of hardware level debug? I'm willing to do whatever research, read 1000 page manuals and such, but I don't know what to start with or whether it's a dead end. \$\endgroup\$
    – J.Todd
    Commented Jun 12, 2021 at 3:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.