Suppose I have some sensitive proprietary software (VHDL/Verilog) on an FPGA connected to my server so I can control it by SSH. Now suppose an attacker compromises my server and can communicate with the FPGA. Could the attacker read the sensitive software off of my FPGA?
Electronic – Reading the program off a FPGA
fpga
Related Solutions
First of all you need to determine what you're going to do with the PDF. If you're displaying it, you'll need some memory for the frame buffer, and a way to interface with the display. That should be your primary concern. Then, start thinking about rendering the PDF itself. As PDFs are essentially compressed PostScript of one form or another with embedded fonts, you can divide your tasks into some major elements:
- part of the FPGA to load data from SD card or other media including file system access
- part of the FPGA to decompress chunks of data, or to accelerate this process
- part of the FPGA to decompress image data (JPEG, PNG, etc.) and copy to memory
- part of the FPGA to decode/execute PostScript
- part of the FPGA to figure out what needs to be displayed (such as the current page); this could be simple bounding logic or complex scaling logic handling a variety of different display modes
- a floating point unit for the floating point coordinates in PostScript
- an integer ALU
- several "GPU" engines which render primitives from the PostScript engine (ideally, in parallel) e.g. draw line, draw polygon, ...
- a font engine or two to render fonts (this will likely be very complex as you will need to support complex features like hinting and antialiasing.)
- a display interface and memory interface
- a UI controller of some kind, perhaps implementing copy/paste, selections, menus, etc.
Ideally the engines 1-5 would be pipelined to get maximum throughput. You'll be looking at a big FPGA to do all of this.
You could probably do this on a CPU, but if you realllly want to do it on an FPGA, this is probably the route to take.
Digital design does not have a lot in common with software development (maybe except that Verilog syntax looks a bit like C language but it just looks). Thus it is very hard to answer this type of question adequately. But as a guy who walked a path from software development to hardware design I'll give it a shot. Looking back at myself, here is how I would have advised myself back then if I knew what I know now:
Start from scratch
Forget everything about software development. Especially programming languages. Those principles do not apply in digital design. It probably would be easy for a guy who designed a CPU to program it in assembler or even C, but an assembler programmer won't be able to design a CPU.
On your learning path do not tend to solve what seem to be an easy problem with your existing knowledge from software. One of the classic examples is a "for loop". Even though you can write a for loop in, say, verilog — it serves a different purposes. It is mainly used for code generation. It may also be a for loop as software developers see it, but it won't be good for anything but simulation (i.e. you won't be able to program FPGA like that).
So for every task you want to tackle, don't think you know how to do it, do a research instead — check books, examples, ask more experienced people etc.
Learn hardware and HDL language
The most popular HDL languages are Verilog and VHDL. There are also vendor-specific ones like AHDL (Altera HDL). Since those languages are used to describe hardware components, they are all pretty much used to express the same thing in a similar fashions but with a different syntax.
Some people recommend learning Verilog because it looks like C. Yes, its syntax is a mix of C and Ada but it doesn't make it easy for a software developer to lean. In fact, I think it may even make it worse because there will be a temptation to write C in Verilog. That's a good recipe for having a very bad time.
Having that in mind, I'd recommend staring from the VHDL. Though Verilog is also OK as long as the above is taken into account.
One important thing to keep in mind is that you must understand what you are expressing with that language. What kind of hardware is being "described" and how it works.
For that reason, I'd recommend you get yourself some book on electronics in general and a good book like this one — HDL Chip Design (aka as a blue book).
Get a simulator
Before you start doing anything in hardware and use any Vendor-specific features etc., get yourself a simulator. I was starting with a Verilog, and used Icarus Verilog along with GTK Wave. Those are free open-source projects. Run examples you see in books, practice by designing your own circuits to get some taste of it.
Get a development board
When you feel like going forward, get a development board. If you know that your employer wants to go with Lattice, then get Lattice board.
The programming methods are very similar, but there are details that are different. For example, different tools, different options, different interfaces. Usually, if you have experience with one vendor, it is not hard to switch. But you probably want to avoid this extra learning curve.
I'd also make sure that the board comes with components that you are planning to use or is extendable. For example, if you want to do design a network device like a router, make sure the board has Ethernet PHY or it can be extended through, say, HSMC connector, etc.
Boards usually come with a good reference, user guide and design examples. Study them.
Read books
You will need to read books. In my case, I had no friends who knew digital design, and this site wasn't very helpful either because of one simple thing — I didn't even know how to phrase my question. All I could come up with was like "Uhm, guys, there is a thing dcfifo and I heard something about clock domain crossing challenges, what is it and why my design doesn't work?".
I personally started with these:
- Advanced Digital Design with the Verilog HDL.
- 100 Power Tips for FPGA Developers
- Advanced FPGA Design - Architecture, Implementation and Optimization.
FPGA vendors have a lot of cookbooks with best practices. Study them along with reference designs. Here is one from Altera, for example.
Come back with more specific questions
While you go through your books, simulate a design, blink some LEDs on your development board, you would, most likely, have a lot of questions. Make sure you don't see an answer to those on the next page of the book or online (i.e. in the Lattice-specific forum) before asking them here.
Best Answer
The bitstream that controls the functionality of your FPGA is normally called the "configuration", not the "software". The configuration bitstream is generated by using FPGA synthesis tools to compile the Verilog/VHDL source code.
There are a number of different ways that the configuration can be transferred into the FPGA each time it "boots up". Roughly, they are:
If an attacker gets control of your server's CPU, then obviously he can read the disk file if the third setup is being used.
If the server's CPU has a direct connection to the FPGA's JTAG interface, then the attacker could read the FPGA configuration either directly from the FPGA, or indirectly by reading the EEPROM device.
In a security-sensitive application, you'll want to use the second setup, with the FPGA reading the configuration from EEPROM, and you'll want to make sure the server CPU does not have access to the FPGA/EEPROM JTAG port. Obviously, you won't store any of the FPGA Verilog/VHDL source code on the server, either.