From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 823DA7460 for ; Fri, 6 Jan 2023 16:01:49 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 42071C433D2; Fri, 6 Jan 2023 16:01:47 +0000 (UTC) Authentication-Results: smtp.kernel.org; dkim=pass (1024-bit key) header.d=zx2c4.com header.i=@zx2c4.com header.b="MJcD+P6R" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zx2c4.com; s=20210105; t=1673020904; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=GBBdu/U+hz6Cjc+bNOWE5qE0BXhjUVEUBxjGp1oqy34=; b=MJcD+P6RLNx85zvcTDbwATN1tyZPlfMj+IMI/v6tpbViVXdxcmKNhOrtlI3XjusmCbv5+x J7TpkFOXiZ4iZ6OI5++8yRhz1LF/WD1nLP6TXO7dsHRPReRqLgS/U1bVqRxHu2ZlnLVq+g zbMdCIya0ydVUzw1sn2CPgnVex97g/c= Received: by mail.zx2c4.com (ZX2C4 Mail Server) with ESMTPSA id d703d995 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Fri, 6 Jan 2023 16:01:44 +0000 (UTC) Date: Fri, 6 Jan 2023 17:01:42 +0100 From: "Jason A. Donenfeld" To: Thorsten Leemhuis , James Bottomley , Peter Huewe , Jarkko Sakkinen , Jason Gunthorpe , Jan Dabros , regressions@lists.linux.dev, LKML , linux-integrity@vger.kernel.org, Dominik Brodowski , Herbert Xu , Johannes Altmanninger , stable@vger.kernel.org, Linus Torvalds , Vlastimil Babka , tbroch@chromium.org, semenzato@chromium.org, dbasehore@chromium.org, keescook@chromium.org Subject: Re: [PATCH v2] tpm: Allow system suspend to continue when TPM suspend fails Message-ID: References: <20230106030156.3258307-1-Jason@zx2c4.com> Precedence: bulk X-Mailing-List: regressions@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20230106030156.3258307-1-Jason@zx2c4.com> Hi Todd & ChromeOS folks, On Fri, Jan 06, 2023 at 04:01:56AM +0100, Jason A. Donenfeld wrote: > TPM 1 is sometimes broken across system suspends, due to races or > locking issues or something else that haven't been diagnosed or fixed > yet, most likely having to do with concurrent reads from the TPM's > hardware random number generator driver. These issues prevent the system > from actually suspending, with errors like: > > tpm tpm0: A TPM error (28) occurred continue selftest > ... > tpm tpm0: A TPM error (28) occurred attempting get random > ... > tpm tpm0: Error (28) sending savestate before suspend > tpm_tis 00:08: PM: __pnp_bus_suspend(): tpm_pm_suspend+0x0/0x80 returns 28 > tpm_tis 00:08: PM: dpm_run_callback(): pnp_bus_suspend+0x0/0x10 returns 28 > tpm_tis 00:08: PM: failed to suspend: error 28 > PM: Some devices failed to suspend, or early wake event detected > > This issue was partially fixed by 23393c646142 ("char: tpm: Protect > tpm_pm_suspend with locks"), in a last minute 6.1 commit that Linus took > directly because the TPM maintainers weren't available. However, it > seems like this just addresses the most common cases of the bug, rather > than addressing it entirely. So there are more things to fix still, > apparently. > > In lieu of actually fixing the underlying bug, just allow system suspend > to continue, so that laptops still go to sleep fine. Later, this can be > reverted when the real bug is fixed. > > Link: https://lore.kernel.org/lkml/7cbe96cf-e0b5-ba63-d1b4-f63d2e826efa@suse.cz/ > Cc: stable@vger.kernel.org # 6.1+ > Reported-by: Vlastimil Babka > Suggested-by: Linus Torvalds > Signed-off-by: Jason A. Donenfeld > --- > This is basically untested and I haven't worked out if there are any > awful implications of letting the system sleep when TPM suspend fails. > Maybe some PCRs get cleared and that will make everything explode on > resume? Maybe it doesn't matter? Somebody well versed in TPMology should > probably [n]ack this approach. When idling scrolling on my telephone to try to see what the implications of skipping TPM_ORD_SAVESTATE could be, I stumbled across some ChromeOS commits related to it, and realized that, ah-hah, finally there's an obvious group of stakeholders who make heavy use of the TPM and have likely amassed some expertise on it. So I was wondering if you'd take a look at this patch briefly to make sure it won't break ChromeOS laptops. Jason