linux-kernel - Re: [PATCH v5 1/1] use crc32 instead of md5 for hibernation e820 integrity check

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 8 Apr 2021 16:55:28 -0700
From:   Eric Biggers <ebiggers@...nel.org>
To:     Chris von Recklinghausen <crecklin@...hat.com>
Cc:     ardb@...nel.org, simo@...hat.com, rafael@...nel.org,
        decui@...rosoft.com, linux-pm@...r.kernel.org,
        linux-crypto@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v5 1/1] use crc32 instead of md5 for hibernation e820
 integrity check

On Thu, Apr 08, 2021 at 11:53:59AM -0400, Chris von Recklinghausen wrote:
> On 4/8/21 11:30 AM, Eric Biggers wrote:
> > On Thu, Apr 08, 2021 at 09:15:06AM -0400, Chris von Recklinghausen wrote:
> > > Suspend fails on a system in fips mode because md5 is used for the e820
> > > integrity check and is not available. Use crc32 instead.
> > > 
> > > This patch changes the integrity check algorithm from md5 to
> > > crc32. This integrity check is used only to verify accidental
> > > corruption of the hybernation data and is not intended as a
> > > cryptographic integrity check.
> > > Md5 is overkill in this case and also disabled in FIPS mode because it
> > > is known to be broken for cryptographic purposes.
> > > 
> > > Fixes: 62a03defeabd ("PM / hibernate: Verify the consistent of e820 memory map
> > >         by md5 digest")
> > > 
> > > Tested-by: Dexuan Cui <decui@...rosoft.com>
> > > Reviewed-by: Dexuan Cui <decui@...rosoft.com>
> > > Signed-off-by: Chris von Recklinghausen <crecklin@...hat.com>
> > > ---
> > > v1 -> v2
> > >     bump up RESTORE_MAGIC
> > > v2 -> v3
> > >     move embelishment from cover letter to commit comments (no code change)
> > > v3 -> v4
> > >     add note to comments that md5 isn't used for encryption here.
> > > v4 -> v5
> > >     reword comment per Simo's suggestion
> > > 
> > >   arch/x86/power/hibernate.c | 35 +++++++++++++++++++----------------
> > >   1 file changed, 19 insertions(+), 16 deletions(-)
> > > 
> > > diff --git a/arch/x86/power/hibernate.c b/arch/x86/power/hibernate.c
> > > index cd3914fc9f3d..b56172553275 100644
> > > --- a/arch/x86/power/hibernate.c
> > > +++ b/arch/x86/power/hibernate.c
> > > @@ -55,31 +55,31 @@ int pfn_is_nosave(unsigned long pfn)
> > >   }
> > > -#define MD5_DIGEST_SIZE 16
> > > +#define CRC32_DIGEST_SIZE 16
> > >   struct restore_data_record {
> > >   	unsigned long jump_address;
> > >   	unsigned long jump_address_phys;
> > >   	unsigned long cr3;
> > >   	unsigned long magic;
> > > -	u8 e820_digest[MD5_DIGEST_SIZE];
> > > +	u8 e820_digest[CRC32_DIGEST_SIZE];
> > >   };
> > > -#if IS_BUILTIN(CONFIG_CRYPTO_MD5)
> > > +#if IS_BUILTIN(CONFIG_CRYPTO_CRC32)
> > Should CONFIG_CRYPTO_CRC32 be getting selected from somewhere?
> 
> 
> Yes, presumably from the same source that sets CONFIG_CRYPTO_MD5. Also
> presumably there's value to not forcing the check if the config value is not
> set.

I wouldn't be so sure about that.  It might just be a bug that CONFIG_CRYPTO_MD5
wasn't being selected.  Where is it documented that the user needed to set
CONFIG_CRYPTO_MD5=y if they wanted the hibernation image checksumming to work?

> > 
> > If that is too hard because it would pull in too much of the crypto API, maybe
> > using the library interface to CRC-32 (lib/crc32.c) would be a better fit?
> 
> 
> Based on my statement above, the intent is to provide a simple drop in
> replacement for md5 so that users of FIPS mode can suspend/resume without
> any errors.
> 

It's possible that most people have CONFIG_CRYPTO_MD5 enabled for some unrelated
reason so the hibernation image checksumming works by chance.
CONFIG_CRYPTO_CRC32 is a different option so the same is not necessarily true.

However, note that CONFIG_HIBERNATION already selects CONFIG_CRC32 (the library
interface to CRC-32) but not CONFIG_CRYPTO_CRC32 (shash interface to CRC-32).

So, if this code just used the library interface crc32_le(), it will always be
available and the IS_BUILTIN() checks can be removed...

- Eric