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 C49D916F0EC; Sat, 2 Nov 2024 10:40:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1730544037; cv=none; b=BYAgUcBjASHxMjACQ4B9zDcnIwLrV/BNAtB6qh9ybTuQUMortBHNVSuK3cmYhTAfaBVKX/CE+xFTHeAphgUIDsvS0yWnC5yJC1MSaJcXfddQ4vBIBzsegSYjlh8kMowclKLD0cOkdDnheRFp2uG1bHdkPuS+qYt5J9zsRRTNt14= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1730544037; c=relaxed/simple; bh=tV3w/NhiYLlSxyTG9f/8MYrM2eWyQSkpoUd6CUZpQ/s=; h=Mime-Version:Content-Type:Date:Message-Id:Cc:Subject:From:To: References:In-Reply-To; b=KxKruc3ZGS3t0h0rZWHQ+YisRnnVUsqtvcg9AQJcsnLiknjVVfo4LPE/JS6wtrrXsgu0HdWESkwPu5+3ol2ikM1qcbFLpy6pJehZ57eoFJSSttu0lgdgcHYT0UyBN9f/+x6cRpHYS9fqJUlCh1algjs8qN5wpOKJtYpQ/VJPhFg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=YqfIep9R; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="YqfIep9R" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 83A74C4CEC3; Sat, 2 Nov 2024 10:40:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1730544037; bh=tV3w/NhiYLlSxyTG9f/8MYrM2eWyQSkpoUd6CUZpQ/s=; h=Date:Cc:Subject:From:To:References:In-Reply-To:From; b=YqfIep9RAimhK5lG8GqaDVHqPzgB0uQJtTNYapUpHHL3VKHD63sfcJEgzueni7hxh cilOlKzjwtdBMAy/OQZ+l0IpY0UmNFTwXCvsHHnr7kkoK/43Rug3DEoVA+M1xExXzq BOTjSEjqGkivPG88YnB5MWaZUg8+CWRWayIW79lY9vYeYXYzUrSgq8nDMHSDKx2rCF 8Q7UW0GpW0FwAXMD9WoKaep1r8yt4QQxPeQLyx1CeRryvMAk5IZgYpA87cz4tAe5PC cmA3WWCIh6wxIYGhm7nB1aprTmMUmQq43pnRUZGmIZNenwodP9jmmhiXWEG730hFGH Ln33GT8WM1epw== Precedence: bulk X-Mailing-List: linux-doc@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Sat, 02 Nov 2024 12:40:31 +0200 Message-Id: Cc: "Jonathan Corbet" , "Peter Huewe" , "Jason Gunthorpe" , , , , , , , , , , , , , , , , , , , , , , , , , , , Subject: Re: [RFC PATCH v2 1/2] tpm, tpm_tis: Introduce TPM_IOC_SET_LOCALITY From: "Jarkko Sakkinen" To: "Jarkko Sakkinen" , "Ard Biesheuvel" X-Mailer: aerc 0.18.2 References: <20241102062259.2521361-1-jarkko@kernel.org> In-Reply-To: On Sat Nov 2, 2024 at 12:38 PM EET, Jarkko Sakkinen wrote: > On Sat Nov 2, 2024 at 11:02 AM EET, Ard Biesheuvel wrote: > > Same for the ioctl() [as well as the read-write sysfs node]: looking > > at the code (patch 19/20) it doesn't seem like user space needs to be > > able to modify this at all, at least not for the patch set as > > presented. So for now, can we just stick with making the sysfs node > > read-only? > > Short answer: I have no idea. I would not mind that but neither > the commit message for TPM give a clue on this. Actually, I *do > not care* if it is RO and RW but I'm neither good at guessing > random shit. > > I haad to assume it was *needed* for reason that I do not know > given that sysfs attribute was RW. Let's put it this way: *if* write is needed this the way to do it now and also in the future (or along the lines). Or least harmful at least (single additional locality change per boot). BR, Jarkko