RFC: generating a header using the linker (CRC calculation)

[Ulf Samuelsson]

The AUTOSARS says CRC-64 ECMA.
It is also popular in Linux.
I have not seen anyone using SHA algorithms or MD5 in any embedded project I have worked with to verify the flash contents.

My proposed implementation would make it easy to use the ISO or ECMA variants, but also allow a user defined polynom.

Best Regards
Ulf Samuelsson


> 
> 15 feb. 2023 kl. 22:29 skrev Paul Koning <paulkoning@comcast.net>:
> 
> 
> 
>> On Feb 15, 2023, at 4:01 PM, Ulf Samuelsson via Binutils <binutils@sourceware.org> wrote:
>> 
>> Some argument for including CRC support in the linker.
>> 
>> ============
>> 
>> The AUTOSAR organisation publishes requirement for developing code for the Automotive industry.
>> 
>> Protecting your code with a CRC is mandatory, and the chosen algorithm is CRC64 ECMA.
>> ...
>> You cannot get a Functional Safety device qualified, if the firmware is not protected by a CRC.
>> ...
>> So there is a significant part of the embedded industry that relies on CRC calculations for ensuring that their systems are not broken.
>> 
>> What is important here is the "Hamming distance" which measures the quality of detection.
>> 
>> The width of the CRC needs to grow as the program size grows.
> 
> Indeed; CRC32 is not suitable for that reason.
> 
> But what about other options?  CRC64 is certainly one reasonable integrity check (if the assumption is that errors are unintentional as opposed to the result of active attack).  But SHA-1, SHA-2, or even MD-5 are at least as good.  Digital signatures provide protection against intentional modification.  Does the standard recognize that those other options are also suitable?
> 
>    paul
>