Monday, September 16, 2013

Back in 2010 when I was first getting into IC RE, John and myself decapped a huge number of chips which have sat around in gel trays in my lab ever since, and never got photographed or added to Silicon Archive.

Earlier today I ran through the first two trays and photographed all of the chips that didn't have wiki pages. The goal here was to get a couple of "as is, where is" images of my entire inventory of dies so I can figure out what I have and what's worthy of further study.

Most of these chips have been sitting around my lab as bare dies for three years. Back then we didn't take package photos or have good record keeping so unfortunately we're not sure what some of these devices are or where they came from.

Sunday, September 15, 2013

As I mentioned in my previous post, libjtaghal supports a socket-based protocol for communicating with JTAG adapters. This allows some very powerful capabilities, for example sharing a single dev board among multiple developers.

The core of this is a TCP server written in C++ known as jtagd. So far I have tested it on Debian 7 on both x86_64-linux-gnu and arm-linux-gnueabihf architectures (laptop computer and Beaglebone Black).

The main jtagd executable connects to a JtagInterface object and bridges it out to a TCP socket using my custom protocol. The protocol is not 100% finalized at this point, several features (like a magic-number banner to verify the client is actually talking to a valid jtagd and not a mistyped port number) will be added before a public release.

Starting a jtagd is quite simple: run "jtagd --list" to see what interfaces are available, then connect to one of them.

Once the jtagd is running, you can connect to it using command-line tools such as jtagclient, or directly from C code using libjtaghal. The example here connects to a Digilent Atlys and verifies the device ID of the XC6SLX45 FPGA.

Note: I originally wrote this in a Facebook note in March 2012, long before any of the recent leaks. I figured it'd be of interest to a wider audience so I'm re-posting it here.

There's been a lot of
hullabaloo lately about Google's new privacy policy etc so I decided to
write up a little article describing my personal opinions on the
subject.

Note that I'm describing defensive policies which may
be a bit more cynical than most people's, and not considering relevant
laws or privacy policies at all. The assumption being made here is that
if it's possible, and someone wants it to happen enough, they will make
it happen regardless of whether it's legal.

RULE 1: If it's on someone else's server, and not encrypted, it's public information.

Rationale: Given the ridiculous number of data breaches we've had
lately it's safe to say that any sufficiently motivated and funded
person / agency could break into just about any company storing data
they're interested in. On top of this, in many countries government
agencies have a history of sending companies subpoenas asking for data
they're interested in, which is typically forked over with little or no
question.

This goes for anything from your Facebook profile to medical/financial records to email.

RULE 1.1: Privacy settings/policies keep honest people honest.

Rationale: Hackers and government agencies, especially foreign
ones, don't have to play by the rules. Services have bugs. Always assume
that your privacy settings are wide open and set them tighter only as
an additional (small) layer of defense.

RULE 2: If it's encrypted, but you don't control the key completely, it's public information.

Rationale: Encryption is only as good as your key management. If
somebody else has the key they're a potential point of failure. Want to
bet $COMPANY's key management isn't as good as yours? Also, if $COMPANY
can be forced/tricked/hacked into turning over the key without your
knowledge, the data is as good as public anyway.

RULE 3: If someone can talk to it, they can root it.

Rationale: It's pretty much impossible to say "there are no
undiscovered bugs in this code" so it's safest to assume the worst...
there is a bug in your operating system / installed software and anyone
with enough time or money can find or buy an 0day. Want to bet there are
NO security-related bugs in the code your box is running? Me neither.
If your system isn't airgapped assume it could have been pwned.

RULE 4: If it goes over an RF link and isn't end-to-end encrypted, it's public information.

Rationale: This includes wifi (even with most grades of WEP/WPA
encryption), cellular links, and everything else of that nature. Sure,
the carrier may be encrypting your SMS/voice calls with some proprietary
scheme of uncertain security, but they have the key so Rule 2 applies.

RULE 5: If you have your phone with you, your whereabouts and anything you say is public information.

Rationale: This can be derived from Rule 3. Your phone is just a
computer and third parties can communicate with it. Since it includes a
microphone and GPS, assume the device has been rooted and they're
logging to $BADGUY on a 24/7 basis.

RULE 6: All available data about someone/something can and will be correlated.

Rationale: If two points of data can be identified as related,
someone will figure out a way to combine them. Examples include search
history (public according to Rule 1), identical
usernames/emails/passwords used on different services, and public
records. If someone knows that JoeSchmoe1234 said $FOO on
GamingForum.com and someone else called JoeSchmoe1234 said $BAR on
HackingForum.com it's a pretty safe bet both comments came from the same
person who's interested in gaming and hacking.

Saturday, September 14, 2013

Almost all of my embedded development and debugging makes heavy use of JTAG, both for loading new bitstreams/firmware images and for interacting with on-chip debug systems.

When I first got into FPGA development I used the Xilinx Platform Cable USB II, which sells for $258.75 on Digikey as of this writing. It integrated nicely with the Xilinx IDE but I quickly grew frustrated. I wanted to use the BSCAN_SPARTAN6 primitive in the FPGA to move debug data on and off the FPGA using JTAG, but Xilinx does not provide any sort of API for scripting the platform cable. Although iMPACT allows manual bit twiddling in the chain as well as executing pre-made SVF files, there is no way to do interactive testing with it

My first step in deciding how to proceed was to see what made their adapter tick. I would have opened up the adapter to see what was inside, but Bunnie saved me the trouble by posting pictures a while ago as the Name That Ware for March 2011.

Xilinx Platform Cable USB II (image courtesy of Bunnie)

The vast majority of the footprints on the board aren't even populated... one can only guess what additional functionality may have been planned at one point. There's an XC3S200A FPGA, a Cypress USB MCU, USB descriptor EEPROM, flash for the FPGA, and then a bunch of passives for power regulation and level shifting. Overall, the design is quite simple and certainly not worth $250.

After browsing for something cheaper and based on a well-known chipset, I found the Digilent HS1, a $54.99 FT2232-based adapter which is supported by Digilent's documented JTAG API and integrated nicely with the Xilinx IDE. In addition, since it's a standard FTDI chipset it would be possible to interact with it at a lower level using libftd2xx. (I also built a custom FT232H-based programmer that I have half a dozen of around my lab, but I wanted a known-good design to verify my software on first.)

The HS1 worked quite well using the Xilinx tools, but I still needed JTAG code to talk to it and interact with the FPGAs for scripted tests. I looked at a couple of popular options and rejected each of them:

OpenOCD (GNU GPL, incompatible with the BSD license used by my work)

xc3sprog (GPL, standalone tool with no API, includes programming algorithms that can run directly off a .bit file)

urjtag (GPL, has a socket-based JTAG server under development but not released yet)

It looked like I was going to have to write my own software, so I sat down and did just that. The result was a C++ library I call libjtaghal (JTAG hardware abstraction layer). It will be released publicly under the 3-clause BSD license once I've cleaned it up a bit; in the meantime if anyone wants a raw code drop with no documentation and a not-quite-finished build system leave a comment and I'll post something.

The basic structure of libjtaghal is built around two core object types: interfaces and devices. A JtagInterface represents a connection to a single JTAG adapter. As of now I support:

FT*232H MPSSE (assumes ADBUS7 is the output enable, an option to configure this is planned for the future)

My custom 8-port JTAG system (more to follow in a future post) will use my socket-based protocol and show up as 8 separate interfaces which can each be controlled independently (potentially from 8 separate client PCs).

A JtagDevice represents a single chip in a scan chain. Support for multi-device scan chains needs a bit more work; this is one of the reasons I haven't released it yet.

A given JtagDevice may implement one or more additional interfaces. Some of these are:

CPLD (generic complex programmable logic device)

FPGA (generic FPGA device)

ProgrammableDevice (any device which accepts firmware of some sort, including CPLDs, FPGAs, MCUs, and JTAG-capable ROMs)

RPCAndDMANetworkInterface (implements RPCNetworkInterface, DMANetworkInterface, and some logic to connect the two protocols)

This design allows several very handy design abstractions. For example, the below code is the sum total of the "program" mode for my "jtagclient" command-line application. It takes a JtagInterface object "iface" and programs the device at chain index "devnum" with the firmware image "bitfile". Note the complete lack of any device- or interface-specific code. The same function can configure a CoolRunner-II via one of my custom FTDI programmers or a Spartan-6 using the integrated Digilent programmer on a dev board without changing anything.

This is part of the test case for my gigabit Ethernet MAC, allocating a page of memory on the device under test by talking to the RAM controller at NoC address "raddr" via the RPCNetworkInterface "iface". (Details on how this is implemented will be coming in a few posts.)

Sunday, September 8, 2013

Earlier today I was working on one of my softcore CPUs and checked the resource usage stats. It turned out that my signed/unsigned 32x32 bit multiplier was using eight DSP48A1 slices. A 32x32 multiplier should only use four so I was quite confused.

After poking around a bit in the synthesis report, it turned out that XST was synthesizing not one, but two multipliers (one signed and one unsigned) and putting a multiplexer on the output, despite me having requested area-optimized synthesis.