> -----Original Message----- > From: Lukasz Hawrylko <lukasz.hawry...@linux.intel.com> > Sent: Wednesday, November 13, 2019 08:24 > To: Gilbert, Travis; pmoo...@cisco.com > Cc: tboot-devel@lists.sourceforge.net > Subject: Re: [tboot-devel] Creating a TXT/tboot policy suitable for a modern > system with TXT+TPM2 > > > Thank you for feedback, I understand your point. I was talking with tools > maintainer and he started working on migration to Python 3.x and better CLI > support (together with documentation how to use it). Our idea is not to add > enormous list parameters to generate LCP with desired options, but to add > JSON/XML file that will describe LCP in human- readable format. After > preparing that file (you can do that in VIM) you will feed it into tool and > than > get LCP. I would like to hear your opinion about that idea. > > The only reason why I don't want to maintain lcptools-v2 is to not have two > tools that do the same thing.
I understand your desire to avoid unnecessary duplication of work. Please understand my frustration with the situation and lack of communication from Intel. I understand that you weren't directly involved at the time, but you're the face now, so you get the complaints :) Intel created a separate tool, lcp-gen2, without mentioning it on the mailing list in the months leading up to its release. Until then we *had* one functioning toolset that everyone else was using for TPM 2.0. It was lcptools-v2. Then Intel abandoned it with no warning. Just pushed a whole new toolset at once. It broke a bunch of testing we had when your ACMs started checking things that lcptools-v2 apparently wasn't writing correctly. Up until the ACM changes, everything was fine. Intel apparently knew this because the lcp-gen2 toolset was merged not too long after and they generated working LCPs. That's the history of the situation in which we now find ourselves. Now that the air is clear, we can move on and work together on a solution. > I hope that with your input we can improve lcp- > gen2 so it can replace lcptools-v2 in every case. In my opinion adding CLI to > GUI application is easier than adding GUI to CLI application, that's why I > decided to go with lcp-gen2. We're very happy to work with Intel to get a solution that meets all our needs. We want TXT to be a robust solution for everyone. > We are working on lcp-gen2 in our local repository, I will ask maintainer when > he will be ready with Python 3.x migration if that will be less than month I > will > wait for that to release new version. > > Lukasz > > On Fri, 2019-11-08 at 18:34 +0000, travis.gilb...@dell.com wrote: > > > -----Original Message----- > > > From: Paul Moore (pmoore2) < > > > pmoo...@cisco.com > > > > > > > Sent: Friday, November 8, 2019 11:19 > > > To: > > > lukasz.hawry...@linux.intel.com > > > ; Gilbert, Travis > > > Cc: > > > tboot-devel@lists.sourceforge.net > > > > > > Subject: Re: [tboot-devel] Creating a TXT/tboot policy suitable for > > > a modern system with TXT+TPM2 > > > > > > On Fri, 2019-11-08 at 12:47 +0100, Lukasz Hawrylko wrote: > > > > For TPM2.0 LCP generation there is a Python tool lcp-gen2 that is > > > > included in tboot's source code. To be honest I didn't try to > > > > generate LCP with tboot's VLP inside but it should work. If not - > > > > this is a bug and need to be fixed. > > > > > > > > lcptools-v2 will is not maintained, any new features like new > > > > signing algorithms will not be included there, so I suggest not to > > > > use it for new designs. We are actively improving lcp-gen2, if > > > > there is something that is missing in your opinion please let me know. > > > > > > A few problems come to mind with lcp-gen2 all of which are blockers: > > > > > > * I see references to upgrading to newer versions of Python 2.x, but > > > nothing about upgrading to Python 3.x; with Python 2.x going EOL in > > > a few months this needs to happen very soon. > > > > > > * No documentation. This is a general problem with the tboot > > > code/tools: there is very little documentation, and what does seem > > > to be present is mostly wrong or incomplete. > > > > > > * The lcp-gen2 tool appears to be intended mostly as a GUI tool, and > > > I need a CLI tool. It looks like there might be some sort of "batch > > > build" available from the command line, but I don't see any further > > > explanation or documentation on this ability. > > > > > > You mention that lcp-gen2 is being actively improved, is this > > > happening offline? The last commit I see is to the sf.net repo for > > > lcp-gen2 is over six months old. > > > > > > If these issues can't be resolved within the next month or two, is > > > there any reason why we couldn't continue to make changes to the > lcptools-v2 tools? > > > > > > -Paul > > > > > > > I'm with Paul. I strongly disagree with discontinuing support for > > lcptools-v2. > > > > lcp-gen2 requires that you have a Window Manager installed. It requires > clicking around in a GUI. Both of these limit its use. The most important > thing > it limits is the ability to script LCP creation like I have done. When I give > someone else an LCP to use, instead of a 10 page document with pictures > that walks them through clicking everything in lcp-gen2, with lcptools-v2, I > can just say "Run this script." If that script doesn't error out, then I > *know* > that the LCP was correctly created. In the lcp-gen2 case, I have to have the > user send me the LCP and other intermediate files and compare them with > what I expect in order to figure out whether something went wrong or not. > Troubleshooting for a script is simpler. If for some reason they can't copy & > paste the console output with the error (very easy), I can have the user run > the script again while redirecting the output to a file, and then send me the > file. > > > > I also have philosophical issues with GUI-only, mostly that it violates the > UNIX philosophy of "Write programs to handle text streams, because that is > a universal interface." My evidence for why this should be considered > consists of my previous paragraph and Paul's concerns. > > _______________________________________________ tboot-devel mailing list tboot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tboot-devel
