archive mirror
 help / color / mirror / 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.



Check out the vibrant tech community on one of the world's most
engaging tech sites,!

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

only message in thread, other threads:[~2018-03-21 23:27 UTC | newest]

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).