Sherry,

In the examples given on the man pages, you have reboot activating
a kernel on a completely different disk.  In such a situation, there is
no reason why the current kernel would have a hash stored in its
"database" that covers this new kernel - thus passing the O_VERIFY
flag would be meaningless.

But this isn't enough.  The hash only verifies that the file on disk that
you're going to execute matches a previously recorded hash for it.
It doesn't engage the TPM in any way and nor can you make any
assertions about the trustworthiness of the new binary.

Darren

Sherry Moore wrote:

>Nico is correct: the running kernel can easily validate the new kernel
>and boot archive by explicitly passing O_VERIFY when opening the
>files.  Once entering the new kernel, the execution is no different
>from a regular boot.
>
>Nico, since the initial manifest itself (used before the the validation
>daemon is fully initialized) is included in the boot archive, I don't
>think there is any data that the running kernel needs to pass to the
>new kernel to access the TPM.  If you believe that there is information
>that needs to be passed, let's chat offline to see how to best achieve
>the purpose.
>
>Thanks,
>Sherry
>
>On Mon, Jun 16, 2008 at 10:11:22AM -0500, Nicolas Williams wrote:
>  
>
>>On Mon, Jun 16, 2008 at 02:13:37PM +0200, Joep Vesseur wrote:
>>    
>>
>>>Restarting the kernel as proposed by this case will either run unverified 
>>>code
>>>(at the vary least, not every step of the boot-process is checked 
>>>sequentially
>>>anymore) or the registers used to record the validation will no longer unlock
>>>the registers containing the sensitive data needed to continue the boot
>>>process.
>>>      
>>>
>>Well, the TPM need not know (because its driver might not actually fully
>>reset it on quiesce?) that a new kernel is replacing the old one.  The
>>old kernel was trusted and it can do signature verification of the new
>>kernel.  And the old kernel could pass to the new kernel any data the
>>new kernel will need to access the TPM.
>>
>>Nico
>>-- 
>>    
>>
>
>  
>


Reply via email to