Received: by 2002:ac0:e350:0:0:0:0:0 with SMTP id g16csp16066imn; Tue, 2 Aug 2022 16:32:23 -0700 (PDT) X-Google-Smtp-Source: AGRyM1sDa9lckKJrsyTTaPhlHbJ/c86rIIWxxEbg2tnq0U570ga3fRCt20okVmk1vEXwwqLym9wn X-Received: by 2002:a17:906:9c82:b0:6e1:2c94:1616 with SMTP id fj2-20020a1709069c8200b006e12c941616mr18184231ejc.64.1659483142692; Tue, 02 Aug 2022 16:32:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1659483142; cv=none; d=google.com; s=arc-20160816; b=ZTeIYOmu0cAWDLYrcdTXnnFoeFRR+xgkNtk+hcf99VLk84T5FxpQypQclNVemyabaf mRDE8C9le+EV5afYY+SQ/w+nsNqZIylKRzgs9bD0nu+APwA5dS2kHpcrwiwFOrOKG1gc W0oMtQ0C4gRQzVaeaX23hlR3ZI+2m1BFqDr9zCIEWJ4DFkfguVKLruToofoN9ds1rqgs NXQ+67WsaNwHSgCbfZDrAh/N5NSEYOLPMTsp1C9qXJ6xw3WBx3VO6ALrT7mgCRcyunCU VxBp4nOJJujnUM8noGZ0DYhvfjcricXoFVtrDt/wVjyLi1WpLe0aOhSr/+fJqOV2Y9Bn oxFg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=ijk2Vsg0Ip8b+c7h4EnuGH9M4RvODJE0xT0wMPg9fns=; b=sscECXa2xMER5LPo7SrD4ZMHQFci/bcU9U8/MvILiXEuJOk9weJHOLIW5n9fFaMlq8 EVVyrd1o/gSYROw3uE0SSqPxZOWVrdvxbi02QyjL9P/Svks1vw7vqwu+P7K5LhtaDLVP MRFTdb8W8HrK9bSEkHJLPhO3aYOVF6K9BpsueTV+yGKapggHs0+heKH4MtdNWwMQ4Y0V yunBAnwFGNznwiYd4wZ3lAbwD8Kc9R/RpTmJ0tpzETgf2WsQ+tn+1uvDD9GFww4IIjvE rzNKCl+y624noxv5javoS3I3EN/MDA+nGXvqX2BEJmvQCTX6FNgYpgADBMLgie3CKgdb Y9kA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=SZgvM3sQ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id t20-20020a170906a11400b00726a3abf022si1708951ejy.781.2022.08.02.16.31.28; Tue, 02 Aug 2022 16:32:22 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=SZgvM3sQ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231514AbiHBWsm (ORCPT + 99 others); Tue, 2 Aug 2022 18:48:42 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42982 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229542AbiHBWsi (ORCPT ); Tue, 2 Aug 2022 18:48:38 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AF7BA1145E; Tue, 2 Aug 2022 15:48:37 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 4B01B60B15; Tue, 2 Aug 2022 22:48:37 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 34E3FC433D6; Tue, 2 Aug 2022 22:48:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1659480516; bh=0dq0SPJ+MNzOXKikEBuNFM2CFX8syRV95tVbi6gKTJI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=SZgvM3sQrPDEN79tnz9pIQmW0z/2fx6mqOAiKu4pQe+ZmpJQLsh+kL2jmgZqoE8rI o3T0KxA8NJyvAfxpi00l6o8szmrfeeJSZy+8WQly1IZ6oy/NMcDA457p8O33Vlq8EJ gmxupBSH61gUZoGgp2bxNyU/hMP7eKY90Rqv1DRW/enkBtwaXVd1UxijtHJhx2TCY7 szFwymnhtLz/b0TWlFwynzmQ8uPxvAUrwZ8Yfjg9EuoOSN13TzQ3ce9byt4h0KQ0Ru I5pDETXYf6XYjXWKTsB1iNY2v3AsN9vOg4UsPfDqdknKHQ6xd84hsNUmFmYsELpaRZ yfjvhIrs51wkw== Date: Tue, 2 Aug 2022 15:48:34 -0700 From: Eric Biggers To: Evan Green Cc: linux-kernel@vger.kernel.org, Matthew Garrett , dlunev@google.com, zohar@linux.ibm.com, jejb@linux.ibm.com, linux-integrity@vger.kernel.org, corbet@lwn.net, rjw@rjwysocki.net, gwendal@chromium.org, jarkko@kernel.org, linux-pm@vger.kernel.org, Len Brown , Pavel Machek , "Rafael J. Wysocki" Subject: Re: [PATCH 08/10] PM: hibernate: Mix user key in encrypted hibernate Message-ID: References: <20220504232102.469959-1-evgreen@chromium.org> <20220504161439.8.I87952411cf83f2199ff7a4cc8c828d357b8c8ce3@changeid> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220504161439.8.I87952411cf83f2199ff7a4cc8c828d357b8c8ce3@changeid> X-Spam-Status: No, score=-7.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 04, 2022 at 04:21:00PM -0700, Evan Green wrote: > +/* > + * Allow user mode to fold in key material for the data portion of the hibernate > + * image. > + */ > +struct uswsusp_user_key { > + /* Kernel returns the metadata size. */ > + __kernel_loff_t meta_size; > + __u32 key_len; > + __u8 key[16]; > + __u32 pad; > +}; Shouldn't the key field be 32 bytes? > +/* Derive a key from the kernel and user keys for data encryption. */ > +static int snapshot_use_user_key(struct snapshot_data *data) > +{ > + struct shash_desc *desc; > + u8 digest[SHA256_DIGEST_SIZE]; > + struct trusted_key_payload *payload; > + struct crypto_shash *tfm; > + int ret; > + > + tfm = crypto_alloc_shash("sha256", 0, 0); > + if (IS_ERR(tfm)) { > + ret = -EINVAL; > + goto err_rel; > + } > + > + desc = kmalloc(sizeof(struct shash_desc) + > + crypto_shash_descsize(tfm), GFP_KERNEL); > + if (!desc) { > + ret = -ENOMEM; > + goto err_rel; > + } > + > + desc->tfm = tfm; > + ret = crypto_shash_init(desc); > + if (ret != 0) > + goto err_free; > + > + /* > + * Hash the kernel key and the user key together. This folds in the user > + * key, but not in a way that gives the user mode predictable control > + * over the key bits. Hash in all 32 bytes of the key even though only 16 > + * are in active use as extra salt. > + */ > + payload = data->key->payload.data[0]; > + crypto_shash_update(desc, payload->key, MIN_KEY_SIZE); > + crypto_shash_update(desc, data->user_key, sizeof(data->user_key)); > + crypto_shash_final(desc, digest); > + ret = crypto_aead_setkey(data->aead_tfm, > + digest, > + SNAPSHOT_ENCRYPTION_KEY_SIZE); > + > +err_free: > + kfree(desc); > + > +err_rel: > + crypto_free_shash(tfm); > + return ret; > +} Just select CRYPTO_LIB_SHA256, and you can use sha256_init/update/final which would be much simpler. Similarly with sha256_data() that is added by the next patch; you could just call sha256(). - Eric