tpmdd-devel Archive on lore.kernel.org
 help / color / Atom feed
* A subtle problem when resuming xen-front and using IMA and multiple TPM devices on the system
@ 2018-03-21 23:27 Stefan Berger
  0 siblings, 0 replies; only message in thread
From: Stefan Berger @ 2018-03-21 23:27 UTC (permalink / raw)
  To: tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
  Cc: Jason Gunthorpe, Jarkko Sakkinen

I tried to convert the IMA code to look up a TPM chip and use it until 
shutdown, when it releases it before device_shutdown(). Ideally this 
would work but because of xen-front's resume code it doesn't. There the 
chip is unregistered upon domU resume (tpmfront_resume calls 
tpmfron_remove) and for that reason IMA cannot be holding onto that chip 
until shutdown. Now the subtle problem comes into play when we were to 
use tpm_vtpm_proxy (with IMA namespaces for example some day) inside a 
domU that is resumed. Upon resume the domU looses its first chip, which 
would be the vTPM accessed via xen-front. IMA now uses 
tpm_pcr_extrend(NULL, ...) to extend a PCR and looks up the first chip 
due to the NULL parameter and now finds a tpm_vtpm_proxy's chip to 
extend the PCR into and this messes up the PCR. So that's bad and only 
in this particular configuration.

Due to how the xen-front works, the solution may be to:
- return -ENODEV from any public TPM API functions in case NULL is being 
passed as chip parameter; do not look up the chip, it will not return 
the one that was there before domU resume
- all subsystems that want to use a TPM have to look it up at the very 
beginning when there is only a hardware TPM there or the domU TPM
    - all these subsystems (looks like IMA and trusted keys) have to 
register a xen-release-tpm-device notifier that is invoked upon 
xen-front resume and causes the subsystems to release the device; upon 
domU resume these subsystems loose their TPM access

Another solution may be to introduce some flags that describe the chips 
and tpm_chip_find_get() would take these flags and check whether a chip 
has these flags set so that IMA and trusted keys wouldn't use a 
tpm_vtpm_proxy in that case.

Comments?

    Stefan






------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, back to index

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-03-21 23:27 A subtle problem when resuming xen-front and using IMA and multiple TPM devices on the system Stefan Berger

tpmdd-devel Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/tpmdd-devel/0 tpmdd-devel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 tpmdd-devel tpmdd-devel/ https://lore.kernel.org/tpmdd-devel \
		tpmdd-devel@lists.sourceforge.net tpmdd-devel@archiver.kernel.org
	public-inbox-index tpmdd-devel


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/net.sourceforge.lists.tpmdd-devel


AGPL code for this site: git clone https://public-inbox.org/ public-inbox