Signature verification prior to startup

reyalp

14117

Re: Signature verification prior to startup

« Reply #10 on: 17 / August / 2013, 15:20:10 »

Advertisements

Quote from: ahull 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.

It does, but it's not clear they will be initialized at this point. IIRC, when I had a too-long blinking sequence in loader entry.S (earliest possible point) code, it did kick in for D10. It may depend on how the camera got their (e.g. diskboot or firm update)

Logged

Don't forget what the H stands for.

srsa_4c

4451

Re: Signature verification prior to startup

« Reply #11 on: 17 / August / 2013, 15:26:54 »

Quote from: reyalp on 17 / August / 2013, 14:57:49

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...

I have several scenarios in mind - all are guesses of course.
- coincidence

- part(s) of ROM got corrupted - either the main ROM, or something in the settings / calibration data area
- some GPIO got switched from input to output or vice versa, and induced actual hardware failure
- the IS processor's firmware or internal config got altered
- the IS hw got into a mechanical position where it shouldn't be
- contact problem around the mecha connector

Logged

reyalp

14117

Re: Signature verification prior to startup

« Reply #12 on: 17 / August / 2013, 17:38:09 »

An additional complication checking values in ROM is that ROM addresses form some cameras are invalid addresses on others. E.g for cameras with ROM starting at FFC00000, looking for a value at FF81.... would cause an exception. This assumes the MPU regions are set up, but I think they will be for diskboot, since the camera already booted once.

Logged

Don't forget what the H stands for.

srsa_4c

4451

Re: Signature verification prior to startup

« Reply #13 on: 18 / August / 2013, 08:31:01 »

Quote from: reyalp on 17 / August / 2013, 17:38:09

An additional complication checking values in ROM is that ROM addresses form some cameras are invalid addresses on others. E.g for cameras with ROM starting at FFC00000, looking for a value at FF81.... would cause an exception. This assumes the MPU regions are set up, but I think they will be for diskboot, since the camera already booted once.

From a quick look, the P-ID seems to be always located at an address which is available for all cameras. It's mostly above 0xfffe0000. The exception can be avoided by checking P-ID first.

Logged

srsa_4c

4451

Re: Signature verification prior to startup

« Reply #14 on: 24 / August / 2013, 09:21:52 »

From the other thread

Quote from: philmoz on 23 / August / 2013, 20:36:24

You could add stubs_entry.S to the loader build with a different version of stubs_asm.h that did not generate any code for the NHSTUB and STUB macros. This would just leave you with the DEF values you can reference in the loader code. DEF values could be added for the id and version string addresses.

However there is only one loader directory for each camera so you would have to make sure the autobuild worked correctly for all firmware versions.

I'm also not sure how you would make this work for the cases where one CHDK version is used on multiple firmware versions - the firmware version string check would fail.

Apparently, the content of camera_list.csv will need to be evaluated too (and even that won't be enough to identify cameras where the only difference is the different P-ID). For cameras with multiple P-IDs an alternative routine could be used, and another alternative routine will be needed for ports which can be used on multiple firmware revisions.

I'm tempted to make a temporary solution for the ixus110, as a generic one is not on the horizon yet...

Logged

srsa_4c

4451

Re: Signature verification prior to startup

« Reply #15 on: 25 / August / 2013, 16:32:59 »

Quote from: srsa_4c on 24 / August / 2013, 09:21:52

I'm tempted to make a temporary solution for the ixus110

So here it is. Not too advanced (everything has to be found manually and typed by hand), and probably not optimal.
I'd appreciate if somebody could review it - it does boot on my 101d camera, and I strongly believe that I have found the correct definitions for the two(three) other revisions, but I may have made a mistake somewhere else.

bootverification_ixus110.diff (3.46 kB - downloaded 30 times.)

Logged

reyalp

14117

Re: Signature verification prior to startup

« Reply #16 on: 28 / August / 2013, 01:53:52 »

Quote from: srsa_4c on 25 / August / 2013, 16:32:59

Quote from: srsa_4c on 24 / August / 2013, 09:21:52
I'm tempted to make a temporary solution for the ixus110
So here it is. Not too advanced (everything has to be found manually and typed by hand), and probably not optimal.
I'd appreciate if somebody could review it - it does boot on my 101d camera, and I strongly believe that I have found the correct definitions for the two(three) other revisions, but I may have made a mistake somewhere else.

Thanks for working on this, and sorry it took me so long to look at it.

It seems like it should work, but there's a lot of room for error typing things in wrong.

If the FWREVADDR were ever not word aligned, it might not behave correctly. In general strings in the firmware can be unaligned, I don't know if this one would ever be.

I think it would be a lot clearer to define the values as strings and have a #include with a minimal version of memcmp to check them.

It seems like a more general way to do this would be to define tables of the compatible PIDs and versions. This would be an include somewhere (in platform/sub, I guess) used by the loader. The defaults could come from the sig finder, but for copied builds you'd have to add the compatible versions manually.

Have you checked what happens when it hits 'forever'? Does the camera shut down after a while, or just not respond until the battery is pulled?

For an invalid firmware version (after the PID check) you should be able to safely flash an LED if you wanted.

Logged

Don't forget what the H stands for.

reyalp

14117

Re: Signature verification prior to startup

« Reply #17 on: 29 / August / 2013, 02:27:03 »

Attached patch is my take on this.

I tested various valid / invalid value combos on my D10, seemed to work OK

The stuff in bin_compat.h could be automated for the sub that was being built, additional subs or platforms would need to be added manually. This include is in platform/sub/* even though it is only used in the loader since it's the obvious place to put something sub-specific. You could do ifdefs in the loader or something instead.

It doesn't handle complicate scenarios where multiple PIDs are compatible but not with the same very (e.g. SX555 100a works only on SX666 100b). I don't think this is a problem since we usually do builds each PID anyway.

In my testing, the watchdog is not hit in any reasonable time for the infinite loop cases, so defining the LED where available would be a good idea.

boot-sig-work-1.patch (4.11 kB - downloaded 35 times.)

Logged

Don't forget what the H stands for.

srsa_4c

4451

Re: Signature verification prior to startup

« Reply #18 on: 30 / August / 2013, 17:15:54 »

Quote from: reyalp on 29 / August / 2013, 02:27:03

Attached patch is my take on this.

Looks good, I guess.
So, the things that are missing:
- build system change (a script?) to generate bin_compat.h from stubs_entry.S, camera_list.csv
- identify equivalent P-IDs if needed (btw. does ps.fi2 of the 'other' camera even work on these 'equivalent' models?)
- mass-editing of files...

For which models should this check be introduced? All DryOS cams, or only for selected models?

Logged