supplierdeeply
« previous next »
Pages: [1] 2 3 4 5 6 ... 9   Go Down

Signature verification prior to startup

  • 83 Replies
  • 14431 Views
*

Offline srsa_4c

  • ******
  • 3602
Signature verification prior to startup
« on: 17 / August / 2013, 09:07:44 »
Advertisements
Inspired by http://chdk.setepontos.com/index.php?topic=10559

As far as I know, CHDK doesn't currently check whether it's started on the hardware it was compiled for. We expect it to crash early on inappropriate hardware.
How about trying to make sure it halts in a pre-defined way, instead of ending up doing something unknown?

I'm thinking about checking 2-3 words in flash, and going into an infinite loop if those are unexpected. The words would be: P-ID (that's a short), and the part of the version string that holds the "GM1.00a" part.
Should this be done in the loader, or is it enough to do it in the platform boot.c before any OS related initialization?
Any thoughts on actual implementation?
Logged
*

Offline waterwingz

  • ******
  • 11471
    • Waterwingz
Re: Signature verification prior to startup
« Reply #1 on: 17 / August / 2013, 09:27:34 »
Quote from: srsa_4c on 17 / August / 2013, 09:07:44
Should this be done in the loader, or is it enough to do it in the platform boot.c before any OS related initialization?
Any thoughts on actual implementation?
If the wrong version is loaded, can we assume it will even get to boot.c?
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline srsa_4c

  • ******
  • 3602
Re: Signature verification prior to startup
« Reply #2 on: 17 / August / 2013, 09:46:47 »
Quote from: waterwingz on 17 / August / 2013, 09:27:34
If the wrong version is loaded, can we assume it will even get to boot.c?
IMHO it mostly will, although most (?) loaders do poke GPIO addresses.
Logged
*

Offline reyalp

  • ******
  • 11269
Re: Signature verification prior to startup
« Reply #3 on: 17 / August / 2013, 14:22:43 »
Quote from: srsa_4c on 17 / August / 2013, 09:46:47
Quote from: waterwingz on 17 / August / 2013, 09:27:34
If the wrong version is loaded, can we assume it will even get to boot.c?
IMHO it mostly will, although most (?) loaders do poke GPIO addresses.
This should be done in the loader, not boot.c IMO.

Note that as I mentioned in the thread, it only applies to cameras with the same dancingbits encodings (for diskboot) since the canon firmware will load and try to run an incorrectly encoded diskboot. However, we can probably assume an invalid instruction will be hit quite quickly in that case.

Since the sigfinder can find the PID and version, it should be possible to check these early in the loader, but some additional work will have to be done to make them available there. Also, we have to deal with cases where the same binary runs on multiple versions.

There's also a few builds that will run on different PIDs too. While we don't use this for official builds, it has proven useful when people have tried it...

The next question is what you do when you find out that it's wrong. You can't shut down. The low exception handlers / romlog code are probably trashed. Possibly call a high (in the romstarter) exception handler, or just go into an infinite loop?
Logged
Don't forget what the H stands for.
*

Offline ahull

  • *****
  • 634
Re: Signature verification prior to startup
« Reply #4 on: 17 / August / 2013, 14:36:38 »
Since CHDK is small in comparison to the size of modern SD cards, would it be possible to have the CHDK startup code load the correct version of CHDK for the camera, assuming it was present on the card.

The idea might be to have a CHDK folder with camera MODEL subfolders (something like IXUS40 IXUS50 A560 and so forth) and f/w VERSION sub-folders beneath that.

In other words, how practical would it be to have a universal boot loader of some description. I have a number of cameras, and have attempted to boot the wrong version on several occasions.

I appreciate this would require some extra thought, and that there are a large number of different variants of CHDK for different cameras and firmwares. Furthermore I suspect it would have a limited appeal, but I thought it worth asking the question.
« Last Edit: 17 / August / 2013, 14:42:09 by ahull »
Logged
*

Offline reyalp

  • ******
  • 11269
Re: Signature verification prior to startup
« Reply #5 on: 17 / August / 2013, 14:41:54 »
Quote from: ahull on 17 / August / 2013, 14:36:38
Since CHDK is small in comparison to the size of modern SD cards, would it be possible to have the CHDK startup code load the correct version if CHDK for the camera, assuming it was present on the card.
Difficult, because you don't know where the IO functions are, and the OS is completely hosed.

The romstarter does have some minimalist loading functions and doesn't change much, but it's definitely not identical between all the cameras.

Plus there's still the diskboot issue I've mentioned before. In that case, doing *anything* in CHDK code is completely ruled out, since the camera will just try to execute garbage generated by incorrectly decoding the binary.

edit:
You could make a canon basic script that acted as a universal loader, but it would be rather cumbersome.
« Last Edit: 17 / August / 2013, 14:48:26 by reyalp »
Logged
Don't forget what the H stands for.
*

Offline ahull

  • *****
  • 634
Re: Signature verification prior to startup
« Reply #6 on: 17 / August / 2013, 14:47:25 »
Well if that is impractical we do need some feedback if we attempt to load on the wrong platform. Again I suspect this is difficult as we wont know the address of the screen, or the LEDs, so we would need some minimalist sigfinder type code or a predefined lookup table to do this if we want to throw some sort of meaningfull error. LEDs might be safer (I'm thinking SOS in morse on one of the blinkenlights). We also need to do some sort of safe landing as previously suggested, so an infininte loop of SOS would be quite good.

« Last Edit: 17 / August / 2013, 14:51:21 by ahull »
Logged
*

Offline reyalp

  • ******
  • 11269
Re: Signature verification prior to startup
« Reply #7 on: 17 / August / 2013, 14:57:49 »
Quote from: ahull on 17 / August / 2013, 14:47:25
Well if that is impractical we do need some feedback if we attempt to load on the wrong platform. Again I suspect this is difficult as we wont know the address of the screen, or the LEDs, so we would need some minimalist sigfinder type code or a predefined lookup table to do this if we want to throw some sort of meaningfull error. LEDs might be safer (I'm thinking SOS on the blinkenlights).
Yes, the display hardware won't be initialized, so displaying anything is right out. No way you will get the correct initialization code for every camera.

It would be theoretically possible to make an LED lookup based on PID, but I'm not sure it's worth it.  Just going into an infinite loop may be good enough. If the romstarter exception code shuts down, that would be better, since it would prevent cam from draining the battery while looking like it wasn't on.
edit: the romstarter doesn't actually contain handlers for anything but boot, so that's out.

Note that not all cameras uses the simple 0x44/0x46 toggle to control LEDs.

I'm not convinced that the IS error that inspired this thread could have been caused by loading the wrong version, but to know for sure we'd need someone else with the same firmware to try it, or identify specifically in the code how it happens. I can imagine that Canon changed the IS initialization code and calling the wrong one somehow tried to make it do something bad...
« Last Edit: 17 / August / 2013, 16:17:28 by reyalp »
Logged
Don't forget what the H stands for.
*

Offline srsa_4c

  • ******
  • 3602
Re: Signature verification prior to startup
« Reply #8 on: 17 / August / 2013, 15:02:27 »
Quote from: ahull on 17 / August / 2013, 14:47:25
or a predefined lookup table to do this if we want to throw some sort of meaningfull error. LEDs might be safer (I'm thinking SOS in morse on one of the blinkenlights)
Yes, we can easily make this basic stuff pretty complex  ;).
I would go for an infinite loop and no feedback - it's the easiest. Downside: the battery will be drained if the user doesn't react.
Logged
*

Offline ahull

  • *****
  • 634
Re: Signature verification prior to startup
« Reply #9 on: 17 / August / 2013, 15:05:11 »
Does the hardware and/or software provide any sort of watchdog? If the DIGIC or the ARM core has a built in watchdog, then it may under the right conditions kick in and do the job for us.
 
Logged
Pages: [1] 2 3 4 5 6 ... 9   Go Up
« previous next »
 

Related Topics