On 6/7/19 10:25 PM, H. Peter Anvin via Syslinux wrote:>> >> However, the CRC polynomial for zlib and the Linux kernel should both be the >> same: 0x04c11db7. > > I just double-checked, and the CRC tables are indeed identical. I was pretty > sure, because I wrote that code a long time ago... >Ah, it seems that zlib's CRC32 returns the binary inverse of the CRC32 (i.e. crc32 ^ 0xffffffff); so unless the Linux code is broken (and the spec needs to be corrected, since that error would go back many years) using the zlib code one would have to look for 0xffffffff == UINT32_MAX instead of 0. -hpa
On 6/7/19 10:34 PM, H. Peter Anvin via Syslinux wrote:> On 6/7/19 10:25 PM, H. Peter Anvin via Syslinux wrote: >>> >>> However, the CRC polynomial for zlib and the Linux kernel should both be the >>> same: 0x04c11db7. >> >> I just double-checked, and the CRC tables are indeed identical. I was pretty >> sure, because I wrote that code a long time ago... >> > > Ah, it seems that zlib's CRC32 returns the binary inverse of the CRC32 (i.e. > crc32 ^ 0xffffffff); so unless the Linux code is broken (and the spec needs to > be corrected, since that error would go back many years) using the zlib code > one would have to look for 0xffffffff == UINT32_MAX instead of 0. >Just double-checked: the spec is correct. So the zlib crc32() routine should return UINT32_MAX == ~(uint32_t)0 == (uint32_t)-1 for a correctly loaded kernel. In case someone is morbidly curious, if Linux had used an inverted CRC, then the final CRC of the kernel image would still have been a constant, but a different one: 0x2144df1c. -hpa
On 6/7/19 10:48 PM, H. Peter Anvin via Syslinux wrote:> On 6/7/19 10:34 PM, H. Peter Anvin via Syslinux wrote: >> On 6/7/19 10:25 PM, H. Peter Anvin via Syslinux wrote: >>>> >>>> However, the CRC polynomial for zlib and the Linux kernel should both be the >>>> same: 0x04c11db7. >>> >>> I just double-checked, and the CRC tables are indeed identical. I was pretty >>> sure, because I wrote that code a long time ago... >>> >> >> Ah, it seems that zlib's CRC32 returns the binary inverse of the CRC32 (i.e. >> crc32 ^ 0xffffffff); so unless the Linux code is broken (and the spec needs to >> be corrected, since that error would go back many years) using the zlib code >> one would have to look for 0xffffffff == UINT32_MAX instead of 0. >> > > Just double-checked: the spec is correct. So the zlib crc32() routine should > return UINT32_MAX == ~(uint32_t)0 == (uint32_t)-1 for a correctly loaded kernel. >And just to double check: gzip -9 bzImage gzip -l -v bzImage.gz method crc date time compressed uncompressed ratio uncompressed_name defla ffffffff Jun 7 22:53 728000 881200 17.4% bzImage ^^^^^^^^ -hpa