eli: Zero pad bytes that arise when certain auth algos are used

[markj]

Summary

When authentication is configured, GELI ensures that the amount of data
per sector is a multiple of 16 bytes. This is done in
eli_metadata_softc(). When the digest size is not a multiple of 16
bytes, this leaves some extra pad bytes at the end of every sector.
This change ensures that they are zeroed before being written to disk.

Reported by: KMSAN
MFC after: 2 weeks

[asomers]

LGTM, but would it be possible to add a test for this in the geli test suite?

[markj]

In D31170#701449, @asomers wrote:

LGTM, but would it be possible to add a test for this in the geli test suite?

FWIW, the test suite is how I found this - I just had to run it with KMSAN configured. Once KMSAN is committed to head I'll work on getting a KMSAN CI job added.

I suppose I could add a test to explicitly check the pad bytes. The idea would be to, for each auth algorithm, create a vnode-backed md, configure a GELI volume on it, overwrite the provider with zeros, detach GELI, and check the pad bytes. I'm not sure how best to do the last part.

[delphij]

Note that this seems to be quite SA worthy as it might leave sensitive data on the drive when these auth algorithms are used (it seems to be HMAC/RIPEMD160 and HMAC/SHA384; is there any other algorithms that are affected), and the fix would be to read in and write every sectors of the provider?

[markj]

In D31170#701527, @delphij wrote:

Note that this seems to be quite SA worthy as it might leave sensitive data on the drive when these auth algorithms are used (it seems to be HMAC/RIPEMD160 and HMAC/SHA384; is there any other algorithms that are affected), and the fix would be to read in and write every sectors of the provider?

Yes, I was planning on requesting at least an EN. HMAC/SHA1 is also affected. And yes I think the only simple way to clear those bytes is to read the entire volume and write it back.