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 :) > Is there any advantage to storing the VLP directly in the TPM and not in > the LCP? > > -Paul > That's a good question. I don't know if customers prefer to use VLP in LCP or directly, I will talk with our application engineers about that. Thanks, Lukasz _______________________________________________ tboot-devel mailing list tboot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tboot-devel
