From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from the.earth.li (the.earth.li [93.93.131.124]) (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 DACC72FFDFF; Mon, 20 Oct 2025 11:43:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=93.93.131.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1760960588; cv=none; b=PokqaxgM77W8sTrlQ9Be+afzU0lxazDGndhXI2Bw9+SwUAXFUjJR8mIb4CIuE75it7njMTtd9BbnMLCmzxtH718+wxbegfmpX8vjThZGaK37ju6KOcU3fKw9iNipQ//fjAfi1dpUoBEvPlgUAz6FLdxgLg8h/dTFjAvc4V76mqI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1760960588; c=relaxed/simple; bh=BVHGhjsqK9b4xu71d6bYhuw8ohlUq0hfSWRFMjoS2us=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=k3W1fRqSYCDwHHY3GUQoNy9QPqQien2Nc+zKo4MjULnhtMwYZgYrKqeohImUbOsG5084FbISbRGMwI6FdUmSV5pAE0Pket5ni/sVhLDrqWy9JYKmfVp0I6f7tg/7kOR/4ckbdl8AGKrb4b6va5pst0O8PUIz+/53AMU2t87tKcw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=earth.li; spf=pass smtp.mailfrom=earth.li; dkim=pass (2048-bit key) header.d=earth.li header.i=@earth.li header.b=ZeskzsYD; arc=none smtp.client-ip=93.93.131.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=earth.li Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=earth.li Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=earth.li header.i=@earth.li header.b="ZeskzsYD" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=earth.li; s=the; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject: Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=sGh+lXCxJLP2PCtNQCSqJwH2PFvRYf3kwyoAPzwi6ko=; b=ZeskzsYDXqPOHB5dSBDe6pqdU/ cvZUjn4eTyzf22cno3nnnFvTDxUhg0jmRWnT2OFEKXS6DH9Tkzg3kgn6u0nGlJuR49ZQKT9TRoSLo Kui0O0lWBkKZG1epYUheSakicRJGGuY9hIbHvCPlQGmBgO/B2j911ORhMwd47rBUAvX/bn34tpP4d R3xIGVqYTyKj8aIxNu80t0upX8+BOzwrFGyqTGTMcbvB2Y9mCkI0EHcxIrakJZBV4EhUVAS71ZYwX kIUu+SLq/aADyTeuyd6RODDLP67z6pLm3d1hZErS6FFqiJXV7GiSpHjur1Z/hDiHFqjyYpPHMBgBa y0ngSvRQ==; Received: from noodles by the.earth.li with local (Exim 4.96) (envelope-from ) id 1vAo5w-0017ul-1Y; Mon, 20 Oct 2025 12:30:32 +0100 Date: Mon, 20 Oct 2025 12:30:32 +0100 From: Jonathan McDowell To: Peter Huewe , Jarkko Sakkinen , Jason Gunthorpe Cc: Linus Torvalds , James Bottomley , linux-integrity@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v3 0/4] pm: Ensure exclusive userspace access when using /dev/tpm Message-ID: References: Precedence: bulk X-Mailing-List: linux-integrity@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: I hit a problem where ~ 1% of TPM firmware upgrades were failing. Investigating revealed the issue was that although the upgrade tool uses /dev/tpm0 this does not actually prevent access via /dev/tpmrm0, nor internal kernel users. It *does* prevent access to others via /dev/tpm0 So the upgrade process started, the HW RNG came in to get some randomness in the middle, did the HMAC context dance, and confused everything to the point the TPM was no longer visible to the OS even after a reboot. Thankfully I've been able to recover those devices, but really what I'd like is the ability for a userspace tool to exclusively access the TPM without something coming in behind it. Given the lightweight attempt at locking that already exists I think this was the original intention. I've reworked this series based on feedback received. Firstly, it's been reordered TPM sharing functionality doesn't break during bisection. Secondly, the O_EXCL check has been tightend up to ensure the caller is also opening the device O_RDWR. Callers shouldn't really be opening the TPM except for reading + writing, but this should help guard against unexpected flags usage a bit more. Finally, this revision keeps the prohibition on more than one user of /dev/tpm#, to avoid unexpected breakages for clients that expect this to guard against multiple invocations. A client only then needs to use O_EXCL if it wants to prevent *all* other access, even with ContextSaves, such as the firmware upgrade case. (I've sent a separate standalone patch that allows the TPM HW RNG to be disabled at run time, and it's now in -next, but even with that I think something like this is a good idea as well.) Jonathan McDowell (4): tpm: Remove tpm_find_get_ops tpm: Add O_EXCL for exclusive /dev/tpm access tpm: Include /dev/tpmrm when checking exclusive userspace TPM access tpm: Allow for exclusive TPM access when using /dev/tpm drivers/char/tpm/tpm-chip.c | 90 +++++++++++++++---------------- drivers/char/tpm/tpm-dev-common.c | 8 +-- drivers/char/tpm/tpm-dev.c | 35 ++++++++++-- drivers/char/tpm/tpm-dev.h | 1 + drivers/char/tpm/tpm-interface.c | 20 +++++-- drivers/char/tpm/tpm.h | 3 +- drivers/char/tpm/tpm2-space.c | 5 +- drivers/char/tpm/tpm_tis_core.c | 3 +- drivers/char/tpm/tpmrm-dev.c | 20 ++++++- include/linux/tpm.h | 4 +- 10 files changed, 124 insertions(+), 65 deletions(-) -- 2.51.0