Locking is Locking,
You don't want to get a thief in you home! Don't put a door in it.... It is useless .
I do not need a protection system in p2, but for the 95% of common code theft, it wil slow them down.
If you do not protect the code, the juridical argument would be that the theft don't know it was copy protected ....
The last 5% just broke the system, they have the power to do it. Don't waste time on them.
When you can get in en out the p2, somebody else can get in and out !
@Peter needs to write a TACHYON kernel using the XBYTE feature and nobody will ever be able to disassemble this and make any sense out of it, if he does not love the Parallax community.
And then we are save!
I am not a fan of FORTH, I would be fine with the P2-HOT monitor, but somehow it makes sense to me.
The reason Basic and Cobol dropped out of the ROM race is very simple, they had zero chance of being selected. Now act so hurt & wounded! as if the final decision is made: Tachyon for ROM!
The reason Basic and Cobol dropped out of the ROM race is very simple, they had zero chance of being selected. Now act so hurt & wounded! as if the final decision is made: Tachyon for ROM!
If any interpreter is going to be added to the P2 ROM it would pretty much have to be Tachyon since it is the only one that currently exists that I am aware of. Developing one from scratch probably can't be done in the required timeframe.
Addit: this is CryptoAuthentication ATECCC508A feature list
* Authentication without the need for secure storage in the host
* No requirement for high-speed computing in client devices
* Cryptographic accelerator with Secure Hardware-based Key Storage
* Performs High-Speed Public Key (PKI) Algorithms
* NIST Standard P256 Elliptic Curve Support * SHA-256 Hash Algorithm with HMAC Option
* Host and Client Operations
* 256-bit Key Length
* Storage for up to 16 Keys
* Two high-endurance monotonic counters
* Guaranteed Unique 72-bit Serial Number
* Internal High-quality FIPS Random Number Generator (RNG)
* 10Kb EEPROM Memory for Keys, Certificates, and Data
* Storage for up to 16 Keys
* Multiple Options for Consumption Logging and One Time Write Information
* Intrusion Latch for External Tamper Switch or Power-on Chip Enablement
* Single Wire or I2C Interface
* 2.0V to 5.5V Supply Voltage Range
Along the same lines, I see Winbond have what they call Secure Flash Memory , which are a combined Crypto engine, and Flash.
"Secure Flash Memory solutions comes with standard HMAC-SHA-256 crypto accelerator and 4 separate Monotonic Flash Counters that are HMAC-signed by individual secret keys. System utilizing each Monotonic Flash Counter can not only verify the integrity and authenticity of the counter values, but also add a timestamp to the message/information transmitted with the resistance to reply attacks. W74M enables system designers to strengthen code/data storage as well as delivers increased security with multi-layered authenticity capability for the emerging IoT devices on the edge or outside the cloud. "
I know this is OT, but I've just gotta say that I'd love to see a FORTH kernel and P2-Hot monitor in the P2 ROM.
The monitor was one of the coolest features of P2-Hot.
There is another thread about P2 monitor, requests are probably best in there.
I'm not sure language kernels should be in ROM ? - there are better uses for ROM, and better ways to manage language features.
If the ROM can read designated/protected Flash areas, (and OTP areas), then having "a FORTH kernel in the P2 ROM" becomes less important.
You could tell the boot loader, to launch forth, via the Flash 'nano-FAT'. To the end user, that appears exactly like 'they booted-forth'.
It could also launch any bytecode language, including Spin 2 - Parallax just needs to provide a flash-file image, compatible with the ROM, and users can update that.
eg Winbond parts look to have 4k top/bottom protect and says Complement Protect bit (CMP) is a non-volatile read/write bit in the status register (S14).
I think that allows a new 'FAT' to be written in the 'other' 4k, and then once verified, that can flip. CMP thus points to which 4K is active, ROM just needs to read that, then look at the info.
I know this is OT, but I've just gotta say that I'd love to see a FORTH kernel and P2-Hot monitor in the P2 ROM.
The monitor was one of the coolest features of P2-Hot.
There is another thread about P2 monitor, requests are probably best in there.
I'm not sure language kernels should be in ROM ? - there are better uses for ROM, and better ways to manage language features.
If the ROM can read designated/protected Flash areas, (and OTP areas), then having "a FORTH kernel in the P2 ROM" becomes less important.
You could tell the boot loader, to launch forth, via the Flash 'nano-FAT'. To the end user, that appears exactly like 'they booted-forth'.
It could also launch any bytecode language, including Spin 2 - Parallax just needs to provide a flash-file image, compatible with the ROM, and users can update that.
eg Winbond parts look to have 4k top/bottom protect and says Complement Protect bit (CMP) is a non-volatile read/write bit in the status register (S14).
I think that allows a new 'FAT' to be written in the 'other' 4k, and then once verified, that can flip. CMP thus points to which 4K is active, ROM just needs to read that, then look at the info.
You're correct that there is really no reason to have anything in the boot ROM other than the boot code. All of these suggestions have been offered as a way to use the extra space. Certainly, having an interpreter in ROM doesn't hurt anything other than maybe a small delay in the boot process.
You're correct that there is really no reason to have anything in the boot ROM other than the boot code. All of these suggestions have been offered as a way to use the extra space. Certainly, having an interpreter in ROM doesn't hurt anything other than maybe a small delay in the boot process.
+1
Nobody that used a Sun workstation or any other computer that ran OpenFirmware was ever disadvantaged or forced to program in Forth just as nobody had to program their printer in PostScript either.
I personally like the idea that I can talk to a chip without the need for a Prop loader running on a PC. So I can just talk to a freshly installed chip via Bluetooth from my phone for instance and reprogram it or test the hardware, and neither do I need a boot chip if it is using an SD card running FAT32.
Is this a case of "throwing the cake in the trash so that nobody gets a piece of it"?
Regarding the fuses can't the following be a safe solution?
1) fuse status/value is shown/overlapped in one hub/cog memory location, or an opcode can read them, only if all of them are untouched/unburned. Else their value is available only to rom code.
2) burn circuitry is enabled only under untouched status
2) the untouched condition is verified at power-up and maintained for the present power-cycle
3) any load/boot source (flash/serial/...) is able to execute a program that issues the burn command and is able to read its status again and comunicate it everywhere, even after reset. It can even try to reissue the burn command a few times in case it not detect the change in status.
4) at next power cycle, since the fuses are not all un-burned, access to them is allowed only to rom code, and the only way to load/execute code is through the fuse-key.
In this case perhaps the burned key will not be exactly the one I wish, but it will still be verified and known.
I can't understand how can later an untouched fuse burn by itself. That means that any part of metal/silicon in the chip can do it either, isn't it? How can such a chip be reliable?
>untouched fuse burn by itself.
The problem is hysteresis, blowing the fuse so spectacularly that there is no chance the state will change a month later.
But the fuse will stop conducting enough electricity and heat to finish the job when 99% of it's gone, or maybe you just did go over by 1% margin.
The 99% maybe go to 100% later or the 101% self heals to 99% later, changing the 256key read-value down the road.
Comments
I doubt anyone could pack more into 16k.
Forth and I don't get along, but... with that little assembler, monitor in there? Maybe.
Is it something that can be dropped in towards the end? Or does it need to be there from the start so they can run those startup simulations?
There is clearly a lot of experience and value, in terms of what could go into ROM.
That's worth something right there. Could you squeeze enough into the remaining 14K to make it worth the effort?
Locking is Locking,
You don't want to get a thief in you home! Don't put a door in it.... It is useless .
I do not need a protection system in p2, but for the 95% of common code theft, it wil slow them down.
If you do not protect the code, the juridical argument would be that the theft don't know it was copy protected ....
The last 5% just broke the system, they have the power to do it. Don't waste time on them.
When you can get in en out the p2, somebody else can get in and out !
@Peter needs to write a TACHYON kernel using the XBYTE feature and nobody will ever be able to disassemble this and make any sense out of it, if he does not love the Parallax community.
And then we are save!
I am not a fan of FORTH, I would be fine with the P2-HOT monitor, but somehow it makes sense to me.
Enjoy!
Mike
Along the same lines, I see Winbond have what they call Secure Flash Memory , which are a combined Crypto engine, and Flash.
http://www.winbond.com/hq/product/code-storage-flash-memory/authentication-flash/?__locale=en&selected=32Mbit(4MB)#categoryArea
"Secure Flash Memory solutions comes with standard HMAC-SHA-256 crypto accelerator and 4 separate Monotonic Flash Counters that are HMAC-signed by individual secret keys. System utilizing each Monotonic Flash Counter can not only verify the integrity and authenticity of the counter values, but also add a timestamp to the message/information transmitted with the resistance to reply attacks. W74M enables system designers to strengthen code/data storage as well as delivers increased security with multi-layered authenticity capability for the emerging IoT devices on the edge or outside the cloud. "
Your post really should be in a separate thread, so as not to confuse authentication with protection. Those are two entirely different issues.
-Phil
The monitor was one of the coolest features of P2-Hot. Having it sure would take the sting out of last-minute design reductions.
And if resident FORTHs (Mecrisp and FISH) for ARM Cortex chips are great (and they are!), how much better to have a kernel from Peter in the P2!
There is another thread about P2 monitor, requests are probably best in there.
I'm not sure language kernels should be in ROM ? - there are better uses for ROM, and better ways to manage language features.
If the ROM can read designated/protected Flash areas, (and OTP areas), then having "a FORTH kernel in the P2 ROM" becomes less important.
You could tell the boot loader, to launch forth, via the Flash 'nano-FAT'. To the end user, that appears exactly like 'they booted-forth'.
It could also launch any bytecode language, including Spin 2 - Parallax just needs to provide a flash-file image, compatible with the ROM, and users can update that.
eg Winbond parts look to have 4k top/bottom protect and says Complement Protect bit (CMP) is a non-volatile read/write bit in the status register (S14).
I think that allows a new 'FAT' to be written in the 'other' 4k, and then once verified, that can flip. CMP thus points to which 4K is active, ROM just needs to read that, then look at the info.
Nobody that used a Sun workstation or any other computer that ran OpenFirmware was ever disadvantaged or forced to program in Forth just as nobody had to program their printer in PostScript either.
I personally like the idea that I can talk to a chip without the need for a Prop loader running on a PC. So I can just talk to a freshly installed chip via Bluetooth from my phone for instance and reprogram it or test the hardware, and neither do I need a boot chip if it is using an SD card running FAT32.
Is this a case of "throwing the cake in the trash so that nobody gets a piece of it"?
1) fuse status/value is shown/overlapped in one hub/cog memory location, or an opcode can read them, only if all of them are untouched/unburned. Else their value is available only to rom code.
2) burn circuitry is enabled only under untouched status
2) the untouched condition is verified at power-up and maintained for the present power-cycle
3) any load/boot source (flash/serial/...) is able to execute a program that issues the burn command and is able to read its status again and comunicate it everywhere, even after reset. It can even try to reissue the burn command a few times in case it not detect the change in status.
4) at next power cycle, since the fuses are not all un-burned, access to them is allowed only to rom code, and the only way to load/execute code is through the fuse-key.
In this case perhaps the burned key will not be exactly the one I wish, but it will still be verified and known.
I can't understand how can later an untouched fuse burn by itself. That means that any part of metal/silicon in the chip can do it either, isn't it? How can such a chip be reliable?
The problem is hysteresis, blowing the fuse so spectacularly that there is no chance the state will change a month later.
But the fuse will stop conducting enough electricity and heat to finish the job when 99% of it's gone, or maybe you just did go over by 1% margin.
The 99% maybe go to 100% later or the 101% self heals to 99% later, changing the 256key read-value down the road.