Re: [tpmdd-devel] [PATCH 09/13] tpm: Pull everything related to sysfs into tpm-sysfs.c

[Daniel De Graaf <dgdegra@tycho.nsa.gov>]

On 09/23/2013 04:42 PM, Jason Gunthorpe wrote:
> On Mon, Sep 23, 2013 at 04:20:51PM -0400, Daniel De Graaf wrote:
>
>> That's fine; it wasn't really advertised in the description, and was
>> mostly added in order to demonstrate the locality security label binding
>> in Xen's vtpm-stubdom.
>
> Ok, lets take it out for now then? I'll send a patch.
>
>>> It looks like this driver was introduced in the 3.12 merge window, we
>>> could drop the attribute, and try to merge a core supported locality
>>> API in 3.13? What do you think?
>>>
>>> But, if you say it is needed, it is easy enough to adjust this patch
>>> series.
>
>> If it's replaced with an alternative, I don't think the sysfs attribute
>> will need to remain.  I am not aware of any clients that currently use
>> this attribute.  The sysfs attribute could remain as the common interface
>> for changing locality, unless you think an ioctl on /dev/tpm0 or
>> something else would be preferable (the attribute was just the simplest
>> way to implement locality switching at the time).
>
> Off the very top of my head:
>
> I suspect that a good API would be a sysfs attribute
> 'default_locality' and an IOCTL to change localities.  The
> default_locality would only take effect when the /dev/tpmX is opened,
> so fiddling with sysfs doesn't break active users.
>
> The struct ops I've added would have a function to change localities,
> some of the generic TPM functions should be revised to have a locality
> argument.
>
> Some thought is needed to determine what locality in-kernel users
> should be using. I suspect userspace and kernel space should not be
> forced to the same locality.
>
> Should user space be restricted to a subset of localities?

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.

Perhaps a .config option would be useful to allow the system designer to
choose what, if any, locality to reserve for kernel use?

> What use models do you see with the security label binding mechanism
> you have on the hypervisor side?
>
> Jason
>

Currently, Xen's virtual TPM restricts certain localities to certain
domains as identified by the domain's security label. For example, a
guest VM may only be allowed to use locality 0-2 (as on real hardware),
while the device model domain associated with the guest is allowed
locality 0-4, and a monitoring/introspection domain must use another
vTPM-only locality (perhaps 5; the TCG can define additional localities
for use in vTPMs).

-- 
Daniel De Graaf
National Security Agency