On Thu, Mar 21, 2019 at 10:46:53AM +0000, Lionel DEBIEVE wrote:
> Hi All,
>
> I'm looking further to debug an issue regarding CRC32 selftests. I'm
> currently blocked on an issue about the second test vector implemented
> on CRC32:
> static const struct hash_testvec crc32_tv_template[] = {
> {
> .plaintext = "abcdefg",
> .psize = 7,
>
> .digest = "\xd8\xb5\x46\xac",
>
> },
>
> I'm currently trying to understand the issue, but using others tools
> (computer or Online CRC calculation), I'm not able to find any way to
> get the expected output? This new vector was introduced for few version
> but I'm wondering who was able to verify it.
>
> Should it be written by byte? Word? Half word?
>
> Thanks for help.
>
> BR,
> Lionel
It's the CRC-32 of the 7-byte buffer "abcdefg" using an initial value of 0.
Bitwise little endian with a little endian digest, and no complementation at the
beginning or end. Note that the initial value ("key") is not given explicitly,
i.e. this tests that the implementation uses the correct default initial value.
The generic, arm, and x86 implementations in the kernel obviously all pass this,
otherwise people would be complaining about them. You can also verify it in
userspace with zlib using:
#include <assert.h>
#include <stdint.h>
#include <zlib.h>
int main()
{
assert((uint32_t)~crc32(~0, "abcdefg", 7) == 0xac46b5d8);
}
(zlib complements the value at the beginning and end, so it must be undone to
match the kernel conversion which doesn't do that.)
- Eric
