We all appreciate your efforts David!
I think that most of us are using your P2Load now on our P2 projects. I certainly could not test my code without P2Load.
I read that Dave was going to focus on propeller-load, but it seems to not have the syntax to support multiple files and offsets like p2load.
Is there a solution like p2load (or a secret option) for writing to the SPI flash?
I would like to burn my arcade font text console to flash so it will automatically load it.
I've updated the top post of the p2load thread with a version that supports writing to flash. Now p2load is actually more powerful than propeller-load in some respects since it can load multiple files and can also write arbitrary data to flash in addition to a bootable image. It also allows you to load up COGs and then reuse the hub memory that would normally be taken up by the COG images for your main program.
I've updated the top post of the p2load thread with a version that supports writing to flash. Now p2load is actually more powerful than propeller-load in some respects since it can load multiple files and can also write arbitrary data to flash in addition to a bootable image. It also allows you to load up COGs and then reuse the hub memory that would normally be taken up by the COG images for your main program.
I've updated the top post of the p2load thread with a version that supports writing to flash. Now p2load is actually more powerful than propeller-load in some respects since it can load multiple files and can also write arbitrary data to flash in addition to a bootable image. It also allows you to load up COGs and then reuse the hub memory that would normally be taken up by the COG images for your main program.
And now the PC half of the flash writer is available to implement the bootloader layout I'm working on!
Ultimately I knew that we would need a wizard to generate keys, sign the bootloader, and encrypt the payload, then program the whole enchilada. In addition, a keyring needs to be implemented where a developer can assign a master key to unlock the keyring and access per-device keys.
At first I thought about having an individual key per field device, but in reality it makes more sense to have "Family" keys. I also postulated using the extra bits as fuses to prevent downgrade attacks. The wizard can burn another fuse and prevent previous firmware revisions from running on the device, protecting it from known exploits.
And now the PC half of the flash writer is available to implement the bootloader layout I'm working on!
Ultimately I knew that we would need a wizard to generate keys, sign the bootloader, and encrypt the payload, then program the whole enchilada. In addition, a keyring needs to be implemented where a developer can assign a master key to unlock the keyring and access per-device keys.
At first I thought about having an individual key per field device, but in reality it makes more sense to have "Family" keys. I also postulated using the extra bits as fuses to prevent downgrade attacks. The wizard can burn another fuse and prevent previous firmware revisions from running on the device, protecting it from known exploits.
Well, not exactly. My loader doesn't use your flash layout. For one thing, I didn't know what you were planning until after I finished my loader. Also, my loader can do multiple loads from flash not just a single one. This is primarly to support the possibly dubious feature of being able to load 7 COGs and then fill hub memory with the main program thereby saving up to 14K of hub memory space. This means that my flash layout has a sequence of opcodes and operands that get executed at load time. These include "LOAD" to load stuff from flash into hub memory, "COGINIT" to start a COG using an image in hub memory, and "START" to start the main program. I guess that is different from what you planned.
The ability to erase and load arbitrary flash locations is all that is needed for the moment. A simple script can glue it all together.
The bootloader has to be signed with a key and hash, then loaded. Then we make a random IV, encrypt the program, then load that. Then the data section is loaded.
While I can roll all of this easily using a shell script and openssl, it will not be that easy for production use because those tools won't be considered acceptable. It will need a QT GUI to make it all happen. I would really like to leverage openssl to do all the crypto stuff. If it were just a unix program, I'd be able to easily make all that happen, but making it also work with Windoze, which is a bit *** backwards, can complicate that.
...
While I can roll all of this easily using a shell script and openssl, it will not be that easy for production use because those tools won't be considered acceptable. It will need a QT GUI to make it all happen. I would really like to leverage openssl to do all the crypto stuff. If it were just a unix program, I'd be able to easily make all that happen, but making it also work with Windoze, which is a bit *** backwards, can complicate that.
Doesn't Mingw/Msys have openssl ?
I get all kinds of hits with this in google: openssl mingw
I remember from your SIDE development that QT does some intelligent things to distance itself from Microsoft. I'll try and setup a development environment for Windoze in my VM. I have installed the Qt designer (whatever they call it now) on my machine, but I don't think it does cross compilation.
The ability to erase and load arbitrary flash locations is all that is needed for the moment. A simple script can glue it all together.
The bootloader has to be signed with a key and hash, then loaded. Then we make a random IV, encrypt the program, then load that. Then the data section is loaded..
I'm hoping it will be possible to merge all of this into propeller-load and p2load at least as an option. Will that be possible? Will you make the crypto stuff in the form of a library that can be linked with other programs? I suppose Steve will want to add the ability to create signed images to SimpleIDE as well.
I'm sure the code base will be reusable, I'm concerned about having a simple interface for managing the encryption, because without a simple interface people won't use it.
I'm sure the code base will be reusable, I'm concerned about having a simple interface for managing the encryption, because without a simple interface people won't use it.
Yes, having a simple interface is certainy imnportant. Do you know if the production ROM loader will allow for unsigned images to be downloaded? Will the current fake signature continue to work on the production chips?
AFAIK, the method will be to sign the code using a key with all zeros, that's what Chip mentioned and that's what the code does currently.
I proposed using a combination of the extra fuses to tell the ROM loader whether the chip expected signed code, he decided it was simpler to just do the exact same logic for every case, thus a zero signed HMAC hash is the result. It also affects the ROM loader, if the chip is "unlocked" then the ROM loader can start if no program starts. If the chip has a key programmed into it, it will only load signed code.
AFAIK, the method will be to sign the code using a key with all zeros, that's what Chip mentioned and that's what the code does currently.
I proposed using a combination of the extra fuses to tell the ROM loader whether the chip expected signed code, he decided it was simpler to just do the exact same logic for every case, thus a zero signed HMAC hash is the result. It also affects the ROM loader, if the chip is "unlocked" then the ROM loader can start if no program starts. If the chip has a key programmed into it, it will only load signed code.
I'm currently "signing" P2 images with 8 longs of $00000001 at the end of the COG image. That's what Chip said was necessary.
I assume that is a hard coded constant on the FPGA code, because the spin code he released doesn't do that.
I'm sure you're right. I guess you're saying that there is no magic number like that for the real P2 chips that will let you boot unsigned code. I guess that means that p2load and propeller-load will have to link with your crypto stuff to be able to load anything into a P2 chip.
We should lobby Parallax to start developing an embedded version of Ruby or Python I guess. Actually, given the Propeller's architecture, maybe Erlang would be best.
I'm sure you're right. I guess you're saying that there is no magic number like that for the real P2 chips that will let you boot unsigned code. I guess that means that p2load and propeller-load will have to link with your crypto stuff to be able to load anything into a P2 chip.
The needed signing algorithms are not very complex, so they could be re-implemented in a nice and portable standalone file that you can include, instead of dragging the whole toybox around that is OpenSSL.
Just a quick thought here: Statically link the encryption for windows. It will be a bigger executable, but nobody will care. That way a UNIX and Windows version look basically the same. User gets the file and it runs.
If the command line version had a -gui or -verbose option, wrapping a GUI around it becomes fairly easy in that the GUI just redirects STDIN, OUT and ERR so that it can display things graphically. Underneath, nothing changes and users are free to run the GUI or command line things and or integrate the command line version into their build chain.
A GUI can be done with the cross platform tools, or can be done native, whichever makes the most sense.
Just a quick thought here: Statically link the encryption for windows. It will be a bigger executable, but nobody will care. That way a UNIX and Windows version look basically the same. User gets the file and it runs.
If the command line version had a -gui or -verbose option, wrapping a GUI around it becomes fairly easy in that the GUI just redirects STDIN, OUT and ERR so that it can display things graphically. Underneath, nothing changes and users are free to run the GUI or command line things and or integrate the command line version into their build chain.
A GUI can be done with the cross platform tools, or can be done native, whichever makes the most sense.
I suppose I should dig out my Qt book and make a GUI version of propeller-load / p2load. But Steve is the GUI guy here! :-)
Comments
I think that most of us are using your P2Load now on our P2 projects. I certainly could not test my code without P2Load.
http://forums.parallax.com/showthread.php/144384-p2load-A-Loader-for-the-Propeller-II
Sounds extremely useful.
And now the PC half of the flash writer is available to implement the bootloader layout I'm working on!
Ultimately I knew that we would need a wizard to generate keys, sign the bootloader, and encrypt the payload, then program the whole enchilada. In addition, a keyring needs to be implemented where a developer can assign a master key to unlock the keyring and access per-device keys.
At first I thought about having an individual key per field device, but in reality it makes more sense to have "Family" keys. I also postulated using the extra bits as fuses to prevent downgrade attacks. The wizard can burn another fuse and prevent previous firmware revisions from running on the device, protecting it from known exploits.
The bootloader has to be signed with a key and hash, then loaded. Then we make a random IV, encrypt the program, then load that. Then the data section is loaded.
While I can roll all of this easily using a shell script and openssl, it will not be that easy for production use because those tools won't be considered acceptable. It will need a QT GUI to make it all happen. I would really like to leverage openssl to do all the crypto stuff. If it were just a unix program, I'd be able to easily make all that happen, but making it also work with Windoze, which is a bit *** backwards, can complicate that.
Doesn't Mingw/Msys have openssl ?
I get all kinds of hits with this in google: openssl mingw
Here's one interesting (QT page, but not QT specific) example: http://qt-project.org/wiki/Compiling-OpenSSL-with-MinGW
Qt for windows relies heavily on Mingw/Msys (except for when it uses that .net stuff).
I proposed using a combination of the extra fuses to tell the ROM loader whether the chip expected signed code, he decided it was simpler to just do the exact same logic for every case, thus a zero signed HMAC hash is the result. It also affects the ROM loader, if the chip is "unlocked" then the ROM loader can start if no program starts. If the chip has a key programmed into it, it will only load signed code.
It is place holder for Magic number.
Chip simplified it in FPGA to be simpler to test loaders
Erlang would be truely awesome.
Another interesting port would be Parrot. http://www.parrot.org/
or lua?
The needed signing algorithms are not very complex, so they could be re-implemented in a nice and portable standalone file that you can include, instead of dragging the whole toybox around that is OpenSSL.
If the command line version had a -gui or -verbose option, wrapping a GUI around it becomes fairly easy in that the GUI just redirects STDIN, OUT and ERR so that it can display things graphically. Underneath, nothing changes and users are free to run the GUI or command line things and or integrate the command line version into their build chain.
A GUI can be done with the cross platform tools, or can be done native, whichever makes the most sense.