Excellent news Chip. I spoke to Peter after your call to him.
We will be able to unprotect the top RAM to modify the code in there won't we, and then protect it again?
16KB at the top sounds great. Solves the interrupt vectors too. And we can hubexec there as well. Just like the old days
BTW for those that don't know, the Mac's (at least the early ones) had a large set of extremely hand crafted (for speed and size) set of callable subroutines that supported the screen drawing, etc, etc. Remember, it was one of the first micros to use WYSIWYG. There were expensive computers like the PERQ etc.
The way this will work is the top 16KB of RAM will always appear at $FC000..$FFFFF. It will be loaded from ROM on reset. A switch via CLKSET can write-protect that area.
For example, for 512KB of hub RAM:
$00000..$7BFFF = first 496KB of hub RAM
$7C000..$FBFFF = empty gap, reads $00
$FC000..$FFFFF = last 16KB of hub RAM, write-protectable (includes debug vectors at end)
I'm going to get the ROM reading away from CLKSET and have it implied for WFBYTE during cog0 cold boot. This will cut ROM loading down to 2 clocks per byte, or 32K clocks, total, which is about 1.5ms.
Many thanks to Chip, Peter, Cluso, Ozpropdev, and all the rest of the folks who have contributed ideas. After adding the boot/bios functions the P2 will truly be an awesome chip. Can't wait to get my hands on one.
I can't remember if this was already discussed for P2 Hot, but even better now if a different COG is planned for checking the SD in parallel with UART...
Why can't we just do a linear search on the SD card?
I mean, not checking every byte, but looking for a longword signature on every sector starting from 0 (up to a relatively large limit), until we find a match.
Then we read a lenght field, the boot image, and checksum. If checksum doesn't match, we won't start execution and resume the search on next sector.
Since cluster size in all newer cards is at least 32KB, we can safely put a bootfile up to that size without concern of fragmentation. Or more if we start with a fresh card.
Still too small for the final image, but you can probably put the entire FAT32 specification in that 32KB, including partition table parsing, a boot menu and long file names.
This method would include the MBR miniboot as a subcase, but also allow to simply drop a file with the boot signature on the first partition.
The only downside I can see is ending with multiple boot files, and having to do some cleanup on the card. But that's the price to pay for a super easy initial setup, I guess.
Any single cog P2 is probably never going to use SD anyway, so even if it tries to coginit there is no harm done by starting up another cog at reset just to look after the SD.
@Cluso99 - Yes, Tachyon is always evolving, just like all good software should, I'm on Linux Mint 18.2 now but that doesn't mean that previous versions weren't usable. The P2 however has been "evolving" and won't be stable until it is locked into silicon. The TAQOZ version of Tachyon for the P2 boot ROM is an even more compact version of the proven Tachyon kernel along with SD drivers and FAT32. I probably will end up with a bytecode version to save memory and this means that any special type of secondary bootloader can be squeezed into the MBR with room to spare. Consider TAQOZ a P2 version of OpenBoot
And so we can solve the security issue! A Tachyon byte code in the MBR. Who would think of that!
But if TAQOS can fit into ROM including FAT32, then there should be any filename and place possible for a boot file and one would not need to modify the MBR of the SD.
So there would be two attempts to boot from SD, first @cluso99 checks MBR and if nothing found to boot from, we end up in TAQOZ checking the file system.
Takes longer, but is more flexible for the user. And if - for commercial applications or such - this flexibility is not wanted, one can use the MBR to boot and overwrite the ROM area to wipe out TACOZ, Monitor and BIOS.
Or use a Flash and do the same.
This is awesome. But the write protect should not be a one shot thing. One should be able to activate and deactivate the write protection.
CEXEOTUA.TAQ a simple command-file for TAQOZ to run at startup. Sounds familiar.
Many thanks to Chip, Peter, Cluso, Ozpropdev, and all the rest of the folks who have contributed ideas. After adding the boot/bios functions the P2 will truly be an awesome chip. Can't wait to get my hands on one.
By the way all, this circles has back around to the system on a chip idea, no OS, but facilities to run apps and do a lot of things concurrently. I'm pretty stoked!
Everything is working well on the new memory mechanism. The whole 16KB ROM transfers to $FC000..$FFFFF in just 32k clock cycles, or 1.5ms @20MHz. No more hub interaction is required to read the ROM bytes. Now, it's just REP+WFBYTE within cog0 before COGINIT, which means that once cog0 loads the ROM into RAM and relaunches from that RAM, the ROM cannot be read again, making the image copied to RAM (or part of it) unrecoverable if the ROM code were to wipe part of it. If we wanted to do some public/private-key encryption, we have the mechanism in place. Not a good idea, I know.
something is wrong here - I write @potatohead long Posts and @potatohead just writes 5 lines?
HELP, I am infected,
MIke
That's hilarious!
The Atari stuff you mentioned was something called xio. As I recall, it was about 8kb of mapped ROM that offered device-independent IO drivers for a few various things, math, interrupt handlers and some other routines, those being related largely to initializing the various chips, mapping certain registers to RAM so they're updated every video frame and general support for the computer. (Keyboard, disk blocks, cassette, screen)
Basic, and other languages, made use of those things and it was fairly standard.
Was a pretty nice set of stuff for your Assembly Language programs, but it omitted all development tools. Major bummer. The Apple ROM was eay more potent, though a little less advanced in the xio way, but did pioneer slots, and how each card could supply its own little ROM.
Frankly the boot stuff is pretty cool. We're going to have a lot of options, and it's going to be easy to use. Home run happening!
What I really want to see at some point is a stripped down spin2, basically a port of Pnut to the P2, which includes PASM as it exists now. That is feature complete. Just need enough SPIN to provide a framework for system code, drivers...
Anything written in that can be done on a PC, or on chip, and given that it's small and lean, that body of codes can be incorporated all over the place later on. I think it's the single most valuable thing we can do.
We probably can end up using a P2 system to develop for P2 targets. Maybe other targets!
Whether those code bodies are used as ROM images or library code isn't as important as the fact that they would all be in this common, baseline simple language that can be incorporated into other environments, with some pre processing.
It's our one shot at a functional object exchange for P2.
Something like that can eventually get done in the sense that it doesn't really need updates. And that's the basis for all the core driver code and the long-term utility of it all.
The good news is we don't have to have this done when the chip is done, due to the nature of how things are going to load in the protected region.
Great idea! I'm into compiling the BeMicro-A9 already (takes over an hour), but how about I add this into the BeMicro-A2 and the DE2-115? Does anyone need the BeMicro-A9 covered?
Great idea! I'm into compiling the BeMicro-A9 already (takes over an hour), but how about I add this into the BeMicro-A2 and the DE2-115? Does anyone need the BeMicro-A9 covered?
I use the BeMicro-A9's microSD now along with two other standard SD sockets. The microSD is available on P36,39,40,41 but having it mapped to the boot config would make it easier for testing.
From Tachyon P2:
IFNDEF *SDCS --- BeMicroCV-A9 on-board microSD
#P39 == *SDCS --- SDCARD CS
#P36 == *SDDO --- Data out from SDCARD
#P41 == *SDCK --- SDCARD clocks
#P40 == *SDDI --- Data to SDCARD
}
For the BeMicro CV-A2 and CV-A9, I used DIP_SW1=ON to redirect the SD card SPI pins to P[61:58]. This is to simulate an SD card being attached for booting.
Here are the two BeMicro files, in case anyone wants to give them a try:
Code security and ROM question... (Sorry if asked already).
Without fuses it seems pretty hopeless, but I was wondering if this would work:
1. ROM or HUB contains secret key for decoding program in external memory
2. Parallax sets up secure web page that encodes programs on demand.
3. There is some flag in program that says program must be decoded
Could this work? One difference is that you'd have to trust Parallax to keep key secret...
One thing that can be done to discourage commercial software theft is to use the customer info to encode their copy of the software as outlined below.
- Use some algorithm to convert the customer info to an encryption/decryption key.
- Include the customer info in the software.
- Use the key to encode their copy of the software.
- Use the key to decode and load the software to the Prop.
Not a perfect solution, but it will at least indicate where the copied software came from and encourage customers to protect it from being copied.
Chip
CV-A2 V27 ID's Ok from Pnut but CV-A9 V27 is non responsive.
I did the recompile, but the new .jic file is identical to the old, bit for bit. I've looked over the code and don't see anything that should be causing trouble. Have you tried it with DIP_SW1 in each position?
One thing that can be done to discourage commercial software theft is to use the customer info to encode their copy of the software as outlined below.
- Use some algorithm to convert the customer info to an encryption/decryption key.
- Include the customer info in the software.
- Use the key to encode their copy of the software.
- Use the key to decode and load the software to the Prop.
Not a perfect solution, but it will at least indicate where the copied software came from and encourage customers to protect it from being copied.
Sorry kwinn, but, if it'll be implemented as depicted in your post, it'll be too easy to decode the encrypted software, disassemble it, and remove every sign of something that can be called a customer info block.
The reason for the above statement is the fact that every P2 will be equal to any other one, then, the encode/decode mechanism should be available to everyone and also the basic keys, or, at least, the position where they are expected to be transmited within some kind of "signon" data block.
Hence, the key and the encode/decode routines will be publicly available to everyone.
By using a simple man-in-the-middle attack, any part of the software could be decoded and modifyed, solely limited by attacker's will.
Sure, after the very beggining of the encoded data stream, under rules that will be readily available to everyone interested in following the stream progression, keys and routines could be changed on the fly, at the original software composer discretion.
It can be made a real pain to eavesdrop it; each and every chameleon colour change will need to be detected and defeated, but the original author will suffer from that pain too.
A lot of sweat, but, no blood, and sure, no tears.
Code security and ROM question... (Sorry if asked already).
Without fuses it seems pretty hopeless, but I was wondering if this would work:
1. ROM or HUB contains secret key for decoding program in external memory
2. Parallax sets up secure web page that encodes programs on demand.
3. There is some flag in program that says program must be decoded
Could this work? One difference is that you'd have to trust Parallax to keep key secret...
This sort of scheme was brought up before (step #1 could even have many such embedded keys), but it does nothing to stop someone from copying the EEPROM. So then you add more layers to the onion and ...
I think that the thing that's missing is that you're supplying everyone with the same set of secrets. So besides the danger of someone discovering this set, you're enabling them to use copied code.
...
I think that the thing that's missing is that you're supplying everyone with the same set of secrets. So besides the danger of someone discovering this set, you're enabling them to use copied code.
That's one reason I suggested using the Unique ID found in many Flash Chips these days.
Even if the ROM Loader does not explicitly tie into one Vendor's Chip, if it allows the PC to Bridge to the Flash device,
then the users download software can read the Serial Number.
(ie allow the PC to send any command to the flash, with the Boot acting as a bridge)
That prevents casual copying - the Flash ID is treated like a Dongle..
...
I think that the thing that's missing is that you're supplying everyone with the same set of secrets. So besides the danger of someone discovering this set, you're enabling them to use copied code.
That's one reason I suggested using the Unique ID found in many Flash Chips these days.
Even if the ROM Loader does not explicitly tie into one Vendor's Chip, if it allows the PC to Bridge to the Flash device,
then the users download software can read the Serial Number.
(ie allow the PC to send any command to the flash, with the Boot acting as a bridge)
That prevents casual copying - the Flash ID is treated like a Dongle..
Perhaps the unique FLASH id and one of many embedded secrets could be used to feed a secure one-way key derivation function. And then the code is decrypted with that derived key. A lot of things would have to be done right, not sure it's a good use of anyone's time to pursue such things.
Comments
We will be able to unprotect the top RAM to modify the code in there won't we, and then protect it again?
16KB at the top sounds great. Solves the interrupt vectors too. And we can hubexec there as well. Just like the old days
BTW for those that don't know, the Mac's (at least the early ones) had a large set of extremely hand crafted (for speed and size) set of callable subroutines that supported the screen drawing, etc, etc. Remember, it was one of the first micros to use WYSIWYG. There were expensive computers like the PERQ etc.
Many thanks to Chip, Peter, Cluso, Ozpropdev, and all the rest of the folks who have contributed ideas. After adding the boot/bios functions the P2 will truly be an awesome chip. Can't wait to get my hands on one.
I can't remember if this was already discussed for P2 Hot, but even better now if a different COG is planned for checking the SD in parallel with UART...
Why can't we just do a linear search on the SD card?
I mean, not checking every byte, but looking for a longword signature on every sector starting from 0 (up to a relatively large limit), until we find a match.
Then we read a lenght field, the boot image, and checksum. If checksum doesn't match, we won't start execution and resume the search on next sector.
Since cluster size in all newer cards is at least 32KB, we can safely put a bootfile up to that size without concern of fragmentation. Or more if we start with a fresh card.
Still too small for the final image, but you can probably put the entire FAT32 specification in that 32KB, including partition table parsing, a boot menu and long file names.
This method would include the MBR miniboot as a subcase, but also allow to simply drop a file with the boot signature on the first partition.
The only downside I can see is ending with multiple boot files, and having to do some cleanup on the card. But that's the price to pay for a super easy initial setup, I guess.
And so we can solve the security issue! A Tachyon byte code in the MBR. Who would think of that!
But if TAQOS can fit into ROM including FAT32, then there should be any filename and place possible for a boot file and one would not need to modify the MBR of the SD.
So there would be two attempts to boot from SD, first @cluso99 checks MBR and if nothing found to boot from, we end up in TAQOZ checking the file system.
Takes longer, but is more flexible for the user. And if - for commercial applications or such - this flexibility is not wanted, one can use the MBR to boot and overwrite the ROM area to wipe out TACOZ, Monitor and BIOS.
Or use a Flash and do the same.
This is awesome. But the write protect should not be a one shot thing. One should be able to activate and deactivate the write protection.
CEXEOTUA.TAQ a simple command-file for TAQOZ to run at startup. Sounds familiar.
Enjoy!
Mike
Ditto!
That's hilarious!
The Atari stuff you mentioned was something called xio. As I recall, it was about 8kb of mapped ROM that offered device-independent IO drivers for a few various things, math, interrupt handlers and some other routines, those being related largely to initializing the various chips, mapping certain registers to RAM so they're updated every video frame and general support for the computer. (Keyboard, disk blocks, cassette, screen)
A current reference that was extended some http://gury.atari8.info/card_xio.php
Basic, and other languages, made use of those things and it was fairly standard.
Was a pretty nice set of stuff for your Assembly Language programs, but it omitted all development tools. Major bummer. The Apple ROM was eay more potent, though a little less advanced in the xio way, but did pioneer slots, and how each card could supply its own little ROM.
Frankly the boot stuff is pretty cool. We're going to have a lot of options, and it's going to be easy to use. Home run happening!
What I really want to see at some point is a stripped down spin2, basically a port of Pnut to the P2, which includes PASM as it exists now. That is feature complete. Just need enough SPIN to provide a framework for system code, drivers...
Anything written in that can be done on a PC, or on chip, and given that it's small and lean, that body of codes can be incorporated all over the place later on. I think it's the single most valuable thing we can do.
We probably can end up using a P2 system to develop for P2 targets. Maybe other targets!
Whether those code bodies are used as ROM images or library code isn't as important as the fact that they would all be in this common, baseline simple language that can be incorporated into other environments, with some pre processing.
It's our one shot at a functional object exchange for P2.
Something like that can eventually get done in the sense that it doesn't really need updates. And that's the basis for all the core driver code and the long-term utility of it all.
The good news is we don't have to have this done when the chip is done, due to the nature of how things are going to load in the protected region.
Three of the FPGA boards already have SD card capability.
Maybe these pins can be mapped to expand boot testing.
Great idea! I'm into compiling the BeMicro-A9 already (takes over an hour), but how about I add this into the BeMicro-A2 and the DE2-115? Does anyone need the BeMicro-A9 covered?
I use the BeMicro-A9's microSD now along with two other standard SD sockets. The microSD is available on P36,39,40,41 but having it mapped to the boot config would make it easier for testing.
From Tachyon P2:
Strangely, the CV-A9 board has a pull-down on the CSn pin.
I'm going to see what I can do about using a DIP switch on each board to pick between the regular P61..P58 pins and the SD card pins.
Here are the two BeMicro files, in case anyone wants to give them a try:
https://drive.google.com/file/d/1N-ozPiluaK9ZnsrPAFtepbkYcZklz00s/view?usp=sharing
For the DE2-115, SW17 redirects P[61:58] to the SD card SPI pins {CSn,CLK,DO,DI}.
CV-A2 V27 ID's Ok from Pnut but CV-A9 V27 is non responsive.
Thanks for letting me know. I will recompile from scratch and we'll see if that fixes the problem. I don't have a BeMicro-A9, myself.
Without fuses it seems pretty hopeless, but I was wondering if this would work:
1. ROM or HUB contains secret key for decoding program in external memory
2. Parallax sets up secure web page that encodes programs on demand.
3. There is some flag in program that says program must be decoded
Could this work? One difference is that you'd have to trust Parallax to keep key secret...
- Use some algorithm to convert the customer info to an encryption/decryption key.
- Include the customer info in the software.
- Use the key to encode their copy of the software.
- Use the key to decode and load the software to the Prop.
Not a perfect solution, but it will at least indicate where the copied software came from and encourage customers to protect it from being copied.
I did the recompile, but the new .jic file is identical to the old, bit for bit. I've looked over the code and don't see anything that should be causing trouble. Have you tried it with DIP_SW1 in each position?
Sorry kwinn, but, if it'll be implemented as depicted in your post, it'll be too easy to decode the encrypted software, disassemble it, and remove every sign of something that can be called a customer info block.
The reason for the above statement is the fact that every P2 will be equal to any other one, then, the encode/decode mechanism should be available to everyone and also the basic keys, or, at least, the position where they are expected to be transmited within some kind of "signon" data block.
Hence, the key and the encode/decode routines will be publicly available to everyone.
By using a simple man-in-the-middle attack, any part of the software could be decoded and modifyed, solely limited by attacker's will.
Sure, after the very beggining of the encoded data stream, under rules that will be readily available to everyone interested in following the stream progression, keys and routines could be changed on the fly, at the original software composer discretion.
It can be made a real pain to eavesdrop it; each and every chameleon colour change will need to be detected and defeated, but the original author will suffer from that pain too.
A lot of sweat, but, no blood, and sure, no tears.
Only my two cents.
Henrique
This sort of scheme was brought up before (step #1 could even have many such embedded keys), but it does nothing to stop someone from copying the EEPROM. So then you add more layers to the onion and ...
I think that the thing that's missing is that you're supplying everyone with the same set of secrets. So besides the danger of someone discovering this set, you're enabling them to use copied code.
That's one reason I suggested using the Unique ID found in many Flash Chips these days.
Even if the ROM Loader does not explicitly tie into one Vendor's Chip, if it allows the PC to Bridge to the Flash device,
then the users download software can read the Serial Number.
(ie allow the PC to send any command to the flash, with the Boot acting as a bridge)
That prevents casual copying - the Flash ID is treated like a Dongle..
Perhaps the unique FLASH id and one of many embedded secrets could be used to feed a secure one-way key derivation function. And then the code is decrypted with that derived key. A lot of things would have to be done right, not sure it's a good use of anyone's time to pursue such things.