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

[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