cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
dquill78
Visitor
Visitor
635 Views
Registered: ‎09-11-2018

Vivado 2015.4's toolchain design limits ability to secure workstations

This isn't just HLS, but also for the other runmode for vivado.

We use vivado 15.4 in an academic setting along with our Nexys 4 boards. Our campus has also upgraded to current generation antivirus, and updated its security policies as well. In today's security concious world, blocking of unsigned scripts is step one. The design of Vivado 15.4's toolchain prevents this. It generates an unsigned javascript script called rundefs.js for each synthesis and implementation. This prevents us from being able to block unsigned scripts and executables because our vivado projects won't build. We cannot even do an exception based on directory or on SHA256 hashes of the scripts because you cannot predict the location of the scripts since they are placed whereever the user happens to make a project, and dependend on how many implementations and sytheses they run, and the content of the script cannot be predicted since they are dependent on what IP's or modules are in the project. If this was out in the wild, then MAYBE it would be acceptable to tell emplyees to only put projects in a particular folder, and then just that folder could have that security policy variance. And I say MAYBE there, because honestly, it is insane that this would have to be the case. To build a product that cannot be run on a secure system is irresponsible. That certianly doesn't work at all in our academic setting, where our users are just being introduced to VHDL, and FPGA's, and design and they don't need ridiculous restrictions like that causing more confusion when they don't even know what they are doing yet. The product, Vivado, is at fault here. That toolchain design is not fit for this time. 

There's also some obnoxious unsigned vbs scripts that vivado uses as well, but at least those only exist in one spot and the files are static so we can just whitelist based on SHA256 hash. 

We still use version 15.4 because, AFAIK, that is the newest version that will still workign with our Artix-7 powered Nexys 4 boards using a free license. A state engineering department such as ours certainly cannot afford to buy licenses for this product. I'm also not certain that the newer versions would solve this issue anyways.  Are there any newer versions that work with our Artix-7 FPGAs the use a proper toolchain that would allow us to secure our machines? Perhaps the application can sign the javascript files it generates, or even abandons generating dynamic scripts all together. A program that generates js, vb, or other scripts on its own is already playing in malware type behaviors and is gonig to be a pain with modern machine learning based anti-virus. 

 

0 Kudos
1 Reply
u4223374
Advisor
Advisor
606 Views
Registered: ‎04-26-2015

Any of the new versions will work fine with the Artix 7 and a free license. 2015.4 is the last one that will work with the Spartan 6 series.

 

I'm pretty sure that you're going to have to give up on HLS completely. Why? Because every time you run a C simulation, that's compiling a standard executable (ie a .exe) in the project directory and running it. That executable can include any standard C code - it can happily write to the filesystem (even though HLS won't allow that during synthesis). This seems like a much bigger security hole for you than a couple of scripts.

0 Kudos