> On 09 May 2016, at 11:39, martin.wi...@ts.fujitsu.com wrote:
>
>
>> I created the VL policy with type "nonfatal" first. With pcr_map=da, PCR-18
>> was the same with different kernels/modules, as expected.
>> (btw it would be nice if a policy violation was visible in some PCR, even
>> with "nonfatal")
>
> PCR 17 and possibly 19 (depending on your PCR settings for VLP) will
> depend on your actual kernel and initrd.
>
True, but the whole point is to have "lists" of multiple allowed combinations
in the policy, and only attest that the policy was fulfilled. I don't know what
actual use a policy of type "nonfatal" is outside of testing, but this seems to
make it worthless - there's nothing to "seal" to (or in other words "nothing to
trust") when no single PCR is both unchanging && only present when policy is
OK. To have an indication that the boot is to be trusted is to look at
PCR-17+PCR-19 but that works has already been done by tboot - it's just not
"visible" anywhere.
Does this make sense?
>> Then I changed the VL policy to "halt", and now PCR-18 is different from
>> before - but I have not even touched NVRAM, so the authorities measurement
>> in PCR-18 should be the same, am I right?
>
> Did you maybe use PCR 18 in your VLP? Check the --pcr option of your
> tb_polgen command line.
>
I don't think so:
tb_polgen --add --num 0 --pcr 17 --hash image --cmdline
"root=UUID=b4b98a60-5b35-4330-ba0e-00a6955ec060 ro consoleblank=64800
intel_iommu=on" --image $kernel vl.pol
tb_polgen --add --num 1 --pcr 19 --hash image --cmdline "" --image $initrd
vl.pol
But I think I found the culprit:
+PCR 18 (Authorities):
+ It will be extended with the following values (in this order):
+ - The values as documented in the MLE Developers Manual
+ - SHA-1 hash of: tboot policy control value (4 bytes) |
+ SHA-1 hash of tboot policy (20 bytes)
+ : where the hash of the tboot policy will be 0s if
+ TB_POLCTL_EXTEND_PCR17 is clear
So PCR-18 get's extended unless this is 0 in tb_polgen:
[--ctrl policy-control-value]
The default value 1 is to extend policy into PCR 17.
How misleading! :)
Thanks
Jan
> Otherwise I don't know. You could check your tboot log for the detailed
> PCR logs, and try to find out the difference.
>
> Martin
>
>>
>> Jan
>>
>>
>>> On 09 May 2016, at 11:01, martin.wi...@ts.fujitsu.com wrote:
>>>
>>> Hi Jan,
>>>
>>>> So I want to use a signed policy, and use multiple policy data files for
>>>> lifecycle management (e.g. when I need to upgrade to MLE but want to be
>>>> able to "rollback" to a previous version if needed).
>>>> Using a signed policy means I don't have to touch the NVRAM (which might
>>>> break something, making rollback impossible).
>>>>
>>>> Sounds right?
>>>
>>> Yes.
>>>
>>>>> There are two ways to install the VLP - either in NVRAM (in which case
>>>>> you're right) or by simply adding it to the LCP as a "custom" element.
>>>>> If you do the latter, and use signed LCP, you don't need to update the
>>>>> NVRAM after a kernel update. You would just update the VLP element
>>>>> integrated in the LCP, and sign the updated LCP.
>>>>
>>>> Is it simply something like:
>>>>
>>>> lcp_crtpolelt --create --type custom --uuid tboot --out vlp.elt vlp.dat
>>>> and then add it vlp.elt to lcp_crtpollist when creating the LCP?
>>>
>>> Assuming that you created vlp.dat with tb_polgen before, yes.
>>>
>>> Regards
>>> Martin
>>>
>>
------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel
