Re: [tboot-devel] Creating a TXT/tboot policy suitable for a modern system with TXT+TPM2

[<Tra...@de...>]

> -----Original Message-----
> From: Paul Moore (pmoore2) <pm...@ci...>
> Sent: Wednesday, November 13, 2019 09:51
> To: luk...@li...; Gilbert, Travis
> Cc: tbo...@li...
> Subject: Re: [tboot-devel] Creating a TXT/tboot policy suitable for a modern
> system with TXT+TPM2
> 
> 
> I'm glad to hear that Python 3.x support is in the works, but I remain
> concerned about the CLI support.  While JSON/XML is better than nothing, it
> still adds a bit of pain for those of us wishing to script the tools; while a
> parameter based approach might not be pretty, it is much easier to script.

Agreed. CLI is a requirement.

> I'm a bit farther down the patch of sorting out the policy patches for the
> TXT/sig work, and as it currently stands it looks like the changes for lcptools-
> v2 is going to be very minor.  Essentially it looks like the only changes I will
> need to make is to add a predefined custom ELT UUID for a certificate
> payload, and even then that is optional (one can specify the UUID on the
> command line if necessary).  

Are you adding the ELT UUID as a policy element plugin similar to mle_elt, sbios_elt, & stm_elt?

> The other changes to the tboot policy would live
> outside lcptools-v2 in tb_polgen.  Would you be open to merging *small*
> patches to lcptools-v2?
> 
> I *really* don't want to have to deal with a GUI and/or JSON/XML if I don't
> have to do so.
> 
> On Wed, 2019-11-13 at 15:23 +0100, Lukasz Hawrylko wrote:
> > 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 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 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, Tra...@de... wrote:
> > > > -----Original Message-----
> > > > From: Paul Moore (pmoore2) <
> > > > pm...@ci...
> > > > Sent: Friday, November 8, 2019 11:19
> > > > To:
> > > > luk...@li...
> > > > ; Gilbert, Travis
> > > > Cc:
> > > > tbo...@li...
> > > >
> > > > 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.
> > >