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

From: Daniel De Graaf
Date: Mon Sep 23 2013 - 18:01:58 EST


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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/