On Tue, 2017-11-14 at 16:59 +0200, Jarkko Sakkinen wrote: > On Sat, Nov 11, 2017 at 01:31:32PM -0700, Jerry Snitselaar wrote: > > > > On Sat Nov 11 17, Jason Gunthorpe wrote: > > > > > > On Sat, Nov 11, 2017 at 12:12:57PM -0700, Jerry Snitselaar wrote: > > > > > > > > > > > Before the release_locality code would only actually release > > > > the locality if the request use bit was set. So after it > > > > grabbed the locality during probe it probably never released > > > > it. The idea with the new code was to release it when it was no > > > > longer needed so another requester would be able to take the > > > > tpm without having to wait for it to be released. > > > > > > If I recall, this was so that system level things outside linux > > > could access the TPM properly?? > > > > > > > Yes, that is what drove this initially. I believe Jarkko was also > > thinking of the possibility in the future where something like a vm > > could request a locality as well, but that is just a hazy > > recollection of emails from back then. > > This was something I recall discussing in LPC 2016 in the hallway at > least :-) A tidbit but it could make sense to tie it to VMM, not VM. I think we should be extremely wary of different localities before we have a cast iron definition of what they mean. All the TPM PC spec says is that locality 4 is reserved for firmware (meaning the kernel should have no access) and it implies there's a privilege hierarchy, making 4 the most privileged and 0 the least but leaves all the definition to the OS. Since we only have four other localities to play with, we need a global definition of what they mean in Linux (and who protects them) otherwise we'll get conflicting uses. What does Windows use them for? James
