I noticed on the kernel mailing list that you said that a major limitation is the speed of the hash function, and how it's purely serial. Rather than post there directly (kernel people are scary!), I figured I'd ask you here.
As I understand it, if you could use a parallel hash function to get the signature of the hibernation image, you would get a massive speed improvement. BLAKE3 is such a hash. While it isn't yet fully matured, it is built on the more heavily-analyzed BLAKE2. BLAKE3 can be fully parallelized, and is very fast even when run on a single thread thanks to it's ability to use SIMD.
I'm not sure of how the addition of new cryptographic functions in the kernel works, but I think it's worth looking into as a next step for this patchset.
Thanks for reading the ramblings of this non-kernel dev!
Power management, mobile and firmware developer on Linux. Security developer at Aurora. Ex-biologist. mjg59 on Twitter. Content here should not be interpreted as the opinion of my employer. Also on Mastodon.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Use a different hash?
Date: 2021-02-23 05:21 pm (UTC)I noticed on the kernel mailing list that you said that a major limitation is the speed of the hash function, and how it's purely serial. Rather than post there directly (kernel people are scary!), I figured I'd ask you here.
As I understand it, if you could use a parallel hash function to get the signature of the hibernation image, you would get a massive speed improvement. BLAKE3 is such a hash. While it isn't yet fully matured, it is built on the more heavily-analyzed BLAKE2. BLAKE3 can be fully parallelized, and is very fast even when run on a single thread thanks to it's ability to use SIMD.
I'm not sure of how the addition of new cryptographic functions in the kernel works, but I think it's worth looking into as a next step for this patchset.
Thanks for reading the ramblings of this non-kernel dev!