> On 09 May 2016, at 12:50, martin.wi...@ts.fujitsu.com wrote: > >> I sort_of_assumed that PCR-18 would only be present if the policy >> verification passed, and would be different different (or all 0s) when the >> verification failed. >> This is a bit dangerous if anyone uses it. > > You need to use "halt" policy. > >> I think something simple like hashing "1" into it when it fails verification >> would make it useful > > If your system is compromised, how do you ensure that this actually > happens? If you use "halt" policy, the system won't boot with a tampered > kernel/initrd unless TXT is off. If TXT is off, PCR 18 will be invalid. > > So my recommendation is: "halt" policy, pcr_map=da, and protect > sensitive data by sealing it against PCR 18. Unless I am overlooking > something, that should be reasonably safe. >
Yes, I get it and for me this is fine. But if anyone wants to use it with "nonfatal" policy (which could be a valid scenario) then this would make it useful - the system will still boot but any secrets won't unseal because of invalid PCR. One can then possibly fix whatever went wrong (like not generating a new policy on kernel upgrade by mistake) without having to powercycle the server, revert the policy etc. In other words, sysadmins usually prefer a booting system they can fix to one that just halts :-) Jan > 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
