On Wed Feb 21, 2024 at 12:37 PM UTC, James Bottomley wrote: > On Tue, 2024-02-20 at 22:31 +0000, Jarkko Sakkinen wrote: > > > > 2. Because localities are not too useful these days given TPM2's > > policy mechanism > > Localitites are useful to the TPM2 policy mechanism. When we get key > policy in the kernel it will give us a way to create TPM wrapped keys > that can only be unwrapped in the kernel if we run the kernel in a > different locality from userspace (I already have demo patches doing > this). Let's keep this discussion in scope, please. Removing useless code using registers that you might have some actually useful use is not wrong thing to do. It is better to look at things from clean slate when the time comes. > > I cannot recall out of top of my head can > > you have two localities open at same time. > > I think there's a misunderstanding about what localities are: they're > effectively an additional platform supplied tag to a command. Each > command can therefore have one and only one locality. The TPM doesn't Actually this was not unclear at all. I even read the chapters from Ariel Segall's yesterday as a refresher. I was merely asking that if TPM_ACCESS_X is not properly cleared and you se TPM_ACCESS_Y where Y < X how does the hardware react as the bug report is pretty open ended and not very clear of the steps leading to unwanted results. With a quick check from [1] could not spot the conflict reaction but it is probably there. > submission). I think the locality request/relinquish was modelled > after some other HW, but I don't know what. My wild guess: first implementation was made when TPM's became available and there was no analytical thinking other than getting something that runs :-) > James [1] https://trustedcomputinggroup.org/wp-content/uploads/PC-Client-Specific-Platform-TPM-Profile-for-TPM-2p0-v1p05p_r14_pub.pdf BR, Jarkko
