On Tue, 2020-01-28 at 22:11 -0500, Paul Moore wrote: > On Sat, Dec 21, 2019 at 12:00 PM Paul Moore (pmoore2) via tboot-devel > < > tboot-devel@lists.sourceforge.net > > wrote: > > On Fri, 2019-12-20 at 10:51 +0100, Lukasz Hawrylko wrote: > > > On Tue, 2019-12-17 at 20:12 +0000, Paul Moore (pmoore2) wrote: > > > > On Fri, 2019-12-06 at 11:37 +0100, Lukasz Hawrylko wrote: > > > > > On Thu, 2019-12-05 at 17:20 +0000, Paul Moore (pmoore2) wrote: > > > > > > A question for discussion: if the VLP is loaded from it's own > > > > > > nvindex, > > > > > > and there is also a VLP present inside the LCP, which VLP do we > > > > > > want > > > > > > to > > > > > > use? I'm assuming it is the VLP we loaded directly, and not > > > > > > from > > > > > > inside > > > > > > the LCP, but thought it was worth checking. > > > > > > > > > > > > > > > > In "stock" TBOOT, VLP loaded from its own index has higher > > > > > priority > > > > > over > > > > > one embedded in LCP, so I agree with you that here it should work > > > > > like > > > > > that. > > > > > > > > I was thinking about this some more and I'm now wondering if we > > > > should > > > > only support the new TB_HTYPE_PECOFF hash type if it is present in a > > > > VLP > > > > loaded from the LCP. In order to use the new signature support > > > > admins > > > > are going to need to generate a new LCP to contain the certificate > > > > payload, why not store the VLP in the LCP at that point? > > > > > > To be honest I don't like to add any kind of limitation when it is not > > > needed. I think that in first approach we should allow to use any of > > > possible configurations. If admins prefer to delete VLP index in TPM > > > and > > > put everything in LCP, they will do it, if, for any reasons, they want > > > to keep VLP under its own index and put only certificate in LCP - why > > > not, we support that case too :) > > > > Okay, that's fine. FWIW, it seems to me as if keeping the VLP in it's > > own nvindex is a bit of a legacy solution, especially when we consider > > the PECOFF signature validation. In the PECOFF case you *must* have a > > LCP to carry the certificates. Not to mention the benefits of a signed > > LCP allowing you to update the policy without updating the values stored > > in the TPM nvindex (assuming the same policy signing key). > > I've been playing with this and it would appear, at least on my TPM2 > system, that loading a VLP directly into the TPM conflicts with the > LCP. > > Lukasz, have you been able to load both a VLP and a LCP into a TPM2? > >
Yes, I had both VLP and LCP loaded in TPM 2.0, I don't think I had any issues with that. How does this conflict look like in your platform? Thanks, Lukasz _______________________________________________ tboot-devel mailing list tboot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tboot-devel
