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

From: Jason Gunthorpe
Date: Mon Sep 30 2013 - 17:20:21 EST

On Mon, Sep 30, 2013 at 04:36:27PM -0400, Daniel De Graaf wrote:

> >I think using CONFIG_ options would make this feature unavaiable to
> >distro kernel users...
> This just moves the problem - now you need a custom initrd instead of
> a custom kernel. Other TPM options like IMA's PCR selection also must
> be changed at CONFIG_ time, although that seems to be more justified
> since IMA in TCB mode is not usable on any distro kernel that makes
> the TPM driver a module (i.e. most or all of them).

A 'custom' initrd is something a distro can automate. Eg a distro's
initrd generation script could read /etc/tpm.cfg and generate an
initrd with the module load and correct sysfs writes. This is more
accessible than recompiling the kernel.

My comments would apply to IMA as well, it should work with standard
distros, meaning the initrd must be able to set it up. So, load the
module in the initrd, setup localities, select the PCR, then enable

The bootloader should measure the kernel and initrd together.

IMHO, distros are not making it easy to enable TPM features, and
requiring a kernel recompile is not helping :)

> There is also the fact that the driver may not be able to tell if a
> locality is available without doing some kind of test command. The
> Xen

Make sense.

> Or, for more flexibility (I actually like this one better):
> And sysfs contains:
> - kernel_locality [0644, int; 0444 if FIXED=y or when locked(?)]
> - lock_kernel_locality [write-once; only exists if FIXED=n]

Yes, this looks simple and sane.

But if there isn't really a need to have a hardwired kernel, the
defaults can be DEFAULT_LOCALITY=0, LOCALITY_FIXED=n and we can
recommend distros rely on the initrd.

> So far, nobody I have talked to has offered any strong opinions on
> what locality should be used or how it should be set. I think finding
> a developer of trousers may be the most useful to talk about how the
> ioctl portion of this would need to be set up - if someone is actually
> needed.

It would be nice to have a user! As I said, we don't use it here.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at