On Thu, 2017-11-09 at 15:12 +0100, Javier Martinez Canillas wrote:
> Hello Patrick,
> 
> On 11/09/2017 01:53 PM, Patrick Ohly wrote:
> > I tried also without tpm2_nvreadlock and without
> > tpm2_takeownership,
> > but neither of that made a difference.
> > 
> 
> Are you sure that the TPM2 state is maintained between VM reboots?

It should be.

> I mean, did
> you try for example making a transient object (i.e: a key) persistent
> using the
> TPM2_EvictControl command and then check if is still listed after a
> VM reboot?
> 
> I wonder if the problem is only with the objects written with
> tpm2_nvwrite or
> anything that ends being persisted in the NVRAM.
> 
> For example, you can try something like the following commands:
> 
> $ tpm2_createprimary -A o -g 0x4 -G 0x25 -C primary.context          
> nameAlg = 0x0004            
> type = 0x0025               
> contextFile = primary.context                           
> 
> CreatePrimary Succeed ! Handle: 0x80ffffff
> 
> $ tpm2_evictcontrol -A o -c primary.context -S 0x81000000            
> persistentHandle: 0x8100000
> 
> And then after a reboot:
> 
> $ tpm2_listpersistent 
> 1 persistent objects defined.
> 
>   0. Persistent handle: 0x81000000
>   {
>         Type: 0x25
>         Hash algorithm(nameAlg): 0x4
>         Attributes: 0x30072
>   }

That works if I keep swtpm running across the reboot. But as with
tpm2_nvdefine (see my other mail to Stefan), the persistent object is
gone after restarting swtpm.

> > Conceptually this is similar to the commands used with TPM 1.2. The
> > simplifying assumption is that only a single OS is getting
> > installed to
> > virgin hardware and then Secure Boot ensures that no other code
> > ever
> > gets access to the active TPM. Therefore a fixed index and no real
> > access protection for the slot are okay. A read-lock is set to
> > ensure
> > that the key is protected from potentially malicious applications
> > which
> >  might have access to /dev/tpm0. Does that sound alright?
> > 
> 
> That sounds reasonable. There are other attack vectors like someone
> replacing your initramfs (that's not signed in a Secure Boot) and
> reading the LUKS pass before the tpm2_nvreadlock.

True. In refkit, the UEFI firmware directly loads a signed UEFI
combined app which contains initramfs, kernel and boot parameters, so
there shouldn't be a way for an attacker to intercept booting before
the initramfs runs.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.