On Fri Feb 23, 2024 at 10:40 PM EET, Jarkko Sakkinen wrote: > On Fri Feb 23, 2024 at 3:57 AM EET, Daniel P. Smith wrote: > > On 2/21/24 14:43, Jarkko Sakkinen wrote: > > > 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. > > > > The expected behavior is explained in the Informative Comment of section > > 6.5.2.4 of the Client PTP spec[1]: > > > > "The purpose of this register is to allow the processes operating at the > > various localities to share the TPM. The basic notion is that any > > locality can request access to the TPM by setting the > > TPM_ACCESS_x.requestUse field using its assigned TPM_ACCESS_x register > > address. If there is no currently set locality, the TPM sets current > > locality to the requesting one and allows operations only from that > > locality. If the TPM is currently at another locality, the TPM keeps the > > request pending until the currently executing locality frees the TPM. > > Right. > > I'd think it would make sense to document the basic dance like this as > part of kdoc for request_locality: > > * Setting TPM_ACCESS_x.requestUse: > * 1. No locality reserved => set locality. > * 2. Locality reserved => set pending. > > I.e. easy reminder with enough granularity. Also for any non-TPM kernel developer this should be enough to get the basic gist of the mechanism without spending too much time reading. BR, Jarkko
