Code Protect
average joe
Posts: 795
After watching the forums for some time, I'm surprised I have not seen anyone posting about this. I'm sure with this kind of access to the source, some formidable protection could be created. Given I'm as much of a verilog newbie as most others here, I have no idea even where to start. Surely someone must be working on this?
Comments
Is there anyone WORKING on this is the question I was asking.
The P2 had a different bootloader to perform the security. That could be transported to the P1V but it will require fuses for the security to work.
So unless the P1V was going to silicon, there seems no point to implement anything on the P1V.
I haven't heard of anyone working on this. Guess we will wait to hear from anyone?
If you write an application that strictly uses the P1 instruction set (a "standard interface"), then you would not have to distribute source. Even if an end-user chose to run your application on the P1V, it would not require your code to be GPLed.
If you write an application that uses the P1V instruction set (i.e. instructions/features not available on the P1), then you would have to also distribute your source under the GPLv3 license (as a derivative work).
Now, what if Parallax creates an ASIC from the P1V source? My guess is that applications would still have to distribute source.
Reading the Wikipedia article on GPL, particularly the section titled "Use of licensed software", I think you can safely classify the P1V source as the "operating system." In which case, code that runs on the P1V would not be required to be GPLed. This would also mean that Parallax could create a P1V ASIC (with user contributions), and your code would still not have to be GPLed.
I agree with Seairth reading of the GPL, however I am not a lawyer.
That's a fair question. It would be nice to hear from someone who actually knows the legality but since very few forum members are lawyers I doubt there will be a definitive answer any time soon.
That may be moot point though, because as far as I can tell from my limited research it's impossible. At least on an FPGA. (cyclone iv &cyclone v) My first thought was to store the key in logic only available during boot but this won't work since the FPGA bitstream isn't encrypted. The only other solution I was able to come up with that seemed remotely possible was to use pins to determine the key (128 pins either connect to VDD or VSS) Both of these ideas make reverse engineering more difficult but not impossible. Neither one affords much more protection than using an unmarked propeller.
About the only way I could see making this even remotely possible would be to make an ASIC with OTP memory. A quick search shows Toshiba and ON Semi have these available.
It really surprises me there isn't more interest in developing a solution. This is one of the major points I've seen discussed when talking about why the P1 isn't used in large, commercial products. The other two big ones are PRICE and product familiarity.
Between the devices currently used in P1V development, Cyclone V ones are explicity mentioned on the body of the application note.
http://www.altera.com/literature/an/an556.pdf
I'm also trying to gather some information about Xilinx devices and the other available sources that were mentioned on the applicable threads.
I hope it helps a bit.
Yanomani
Well that's good news! I'll start looking into the Cyclone V a bit more. Please keep me up to date with the Xilinx devices. I currently use a few of their chips in different designs.
So that means my first idea would be feasible in FPGA. My thought would be to have 4 or 5 longs that map into cog0 on reset. These contain the 128-bit security key as well as any configuration bits. Bootloader functions just like the described P2 bootloader. A program would need to be written to encrypt the eeprom file before it can be sent to be programmed. Then the P2 bootloader would need to be retrofitted to work with the P1v. Quite a bit of work but not quite impossible. Let's say, improbable.
If you are using Xilinx Spartan 6 LX75 and larger devices, yes, they have DNA and AES, two technics that Xilinx uses to enable some kind of copy protection.
There are many application notes and papers on that subject, you can google them at your own pace.
There are also many articles about copy protection defeat, by attacking the foundations of FPGA device construction and operational characteristics,
It's no more a matter of "David and Goliath" fight, but how many Davids, how fast they spin the pebble, how big Goliath can really be, and the real strength of its armour.
This makes me wonder a day will come, when most of the fabric of any logic circuit will be devoted, and sure, will respond for its cost of design, and ultimately, its final price, only to fight against IP subtraction.
And there comes a new legion of hackers and crackers ..... and so on.
Mein Gott In Himmel
Yanomani
However, lack of lawsuits is not the definition of compliance with the law. And therein lies the rub.
The GPL has never been tested in court and, as a result, it's interpretation is not supported any case law whatsoever. There are certainly plenty of Open Source supporters, zealots and bigots who are happy to interpret the various License Agreements. But the facts remain that especially where linkage between Open Source and closed source implementations occurs at execution time, whether through dynamic linking or cross-process activation or non-static invocation, the Agreements are difficult to interpret. Frankly it's as if they were written by those who either didn't understand modern delivery strategies.
Bottom line - caveat emptor.
Not that I want to hijack this thread, but the GPL has prevailed in court. The most well-known example of an aggressive fighter for the GPL is probably Busybox, whose makers have won (or gotten setllements in) several lawsuits.
I can also tell you from first-hand experience that big companies take open-source software very seriously. I was part of a transfer of ownership of a piece of software between two companies, and they used a tool called Black Duck to make sure that there was no chance that there were any GPL-like licenses on any parts of our software that would ever force either party to disclose the source code of the entire software.
===Jac