Decoupling from zlib

[Earl Chew]

As explained in configure.ac:

> AC_CHECK_LIB([z], [crc32], [], [AC_MSG_ERROR([need crc32 implementation from libz])])

The CRC32 implementation comprises a lookup table, and a short loop to process the data.

The main purpose of zlib is to support compression, and I wonder if it is worth taking this dependency for a relatively straightforward checksum implementation.

I also notice that there is an implementation of precisely the same CRC32 algorithm in gnu-efi, and EFI Boot Guard already depends on gnu-efi.

Today, the dependency on crc32 in zlib means that users of libebgenv.a need to link -lz (as named in libebgenv.pc). Changing that to a dependency on gnu-efi (for CalculateCrc) would mean that users of libebgenv.a would instead need to link -lefi. Though there is a zlib.pc for the current use case, there is no matching gnuefi.pc available as far as I know.

With that in mind, I think the most appropriate simplification is to provide a crc32() implementation in EFI Boot Guard itself (eg env/crc32.c).

Is there any appetite to remove this dependency on zlib?

Are there other features planned which potentially depend on zlib?

Earl

[Jan Kiszka]

Valid points, and I don't think that we will need compression in EBG in
the foreseeable future. Happy to see any patch suggestions for moving to
dedicated crc32 implementation. Maybe the one from gnuefi is statically
linked anyway when using it?

Jan

--
Siemens AG, Technology
Competence Center Embedded Linux