[PATCH] SoC: cros_ec_codec: switch to library API for SHA-256

[Tzung-Bi Shih]

On Fri, May 15, 2020 at 2:50 PM Ard Biesheuvel <ardb at kernel.org> wrote:
> In this case, you are using the digest to decide whether the same code
> has already been loaded, right?
>
> So it makes sense to think about the threat model here: if you are
> able to defeat the strong hash, what does that buy an attacker? If an
> attacker is able to create a different piece of code that has the same
> digest as the code that was already loaded, the only thing that
> happens is that the loader will ignore it. If that is a threat you
> want to protect yourself against, then you need sha256. Otherwise, a
> crc is sufficient.

My original intention is to:
- avoid transmitting duplicate data if remote processor already has
the same binary blob (be reminded that the transmission may be costly)
- check integrity if any transmission error

Not considering preventing an attacker in the original design.  If an
attacker can send arbitrary binary blobs to the remote processor (via
a dedicated SPI or a specific memory region), the attacker should
already "root" the kernel and the device.

I understand your point that CRC should be sufficient in the use case.
However here are my considerations:
- as the payload is possibly executable, I would like to use stronger
hash to pay more attention
- calling calculate_sha256() is in-frequent, I don't really see a
drawback if it is almost one time effort

If we want to switch to use CRC32, we cannot change the kernel code
only.  There is an implementation of a remote processor that also
needs to modify accordingly.  I will keep in mind whether to switch to
use CRC32 next time when we are revisiting the design.

> In general, you shouldn't use crypto at all unless you can explain why
> it is necessary.

When you are mentioning "crypto", do you refer to both crc32 and
sha256 in the case?