Messages in this thread | | | Date | Mon, 23 Sep 2013 16:23:24 -0600 | From | Jason Gunthorpe <> | Subject | Re: [tpmdd-devel] [PATCH 09/13] tpm: Pull everything related to sysfs into tpm-sysfs.c |
| |
On Mon, Sep 23, 2013 at 06:00:46PM -0400, Daniel De Graaf wrote:
> In a PC client TPM, normal OS code (as opposed to firmware or microcode) > is already restricted to locality 0-2. It may make sense to restrict > locality 2 to the kernel, which would allow an in-kernel TPM seal > command to be able to bind data so that userspace cannot unseal it. > However, only allowing localities 0 and 1 to userspace may be too > restrictive if userspace also wishes to use locality for separation, > since locality 1 does not have the ability to reset any PCRs that > locality 0 cannot also reset. > The kernel could reserve only locality 1 for its own use, giving it the > ability to seal data but not interfering with the ability to reset PCRs. > This would be my preference, although it is less intuitive to allow code > of lower privilege (userspace) to control the higher numbered locality > 2.
This matches my vague understanding (we don't use localities here)
>> Perhaps a .config option would be useful to allow the system designer to >> choose what, if any, locality to reserve for kernel use?
A runtime sysfs seems reasonable..
Would: user_default_locality kernel_default_locality user_allowed_localities (bitmask) supported_localities (bitmask) a GET_LOCALITY/SET_LOCALITY IOCTL to change localities of an open'd /dev/tpmX
Do the job?
At first glance anyhow. I wonder what in-kernel users would be impacted by localities..
Any thoughts on root vs not-root? Would middelware want to use localities?
Do you know anyone on the userspace SW side who could look at this?
Jason
| |