tboot-devel — Developer support

Re: [tboot-devel] [RFC] tboot: kernel signature verification

[Lukasz H. <luk...@li...>]

On Fri, 2019-12-06 at 21:28 +0000, Paul Moore (pmoore2) wrote:
> I know I've said this before, but please consider all of this code still
> a very rough prototype.  Normally I wouldn't share code of this quality,
> but since there are a large number of uncertainties surrounding this
> work (e.g. is this approach reasonable?  are the policy changes okay?
> etc.) I felt the advantages of sharing this code at such an early stage
> outweighed the risks.

I totally understand that, it's nice that you are sharing your WIP code,
so we can discuss changes on the fly. If I wrote something that suggests
that I blame you for that, it's only a result of fact that English
is not my native language :)

Thanks,
Lukasz

Re: [tboot-devel] [RFC] tboot: kernel signature verification

[Paul M. (pmoore2) <pm...@ci...>]

On Fri, 2019-12-06 at 11:37 +0100, Lukasz Hawrylko wrote:
> On Wed, 2019-12-04 at 14:33 +0000, Paul Moore (pmoore2) wrote:
> > Can you elaborate a bit more on what you mean by "the root of
> > certificate"?  Alternatively, could you upload the kernel and
> > signing
> > certificate somewhere I could grab so I can play with it?
> 
> Maybe I used wrong words, I am talking about pkcs1_search_signer
> function and following lines:
> 
>   if (!asn1_blob_cmp(&entry->cert.serial, serial) &&
>       !asn1_blob_cmp(&entry->cert.ca->subject, subject))
> 
> If I change them to
> 
>   if (!asn1_blob_cmp(&entry->cert.serial, serial) &&
>       !asn1_blob_cmp(&entry->cert.subject, subject))
> 
> it will find my certificate.

Thanks, that makes it much more clear.  One of the benefits of sharing
code is that it helps remove any uncertainties. :)

> Could you please explain me why are you
> using serial from root of entry and subject from sub-element? Is it
> connected with certificate chain? What if there is just the simplest
> possible certificate that is not signed by anybody?

That does look a little odd, doesn't it?  It's likely left over from a
rework of the code during development that wasn't caught because of 1)
it worked on my Fedora based test cases, and 2) I haven't really gone
over all of the code yet to make sure it is "sane" ;)

I know I've said this before, but please consider all of this code still
a very rough prototype.  Normally I wouldn't share code of this quality,
but since there are a large number of uncertainties surrounding this
work (e.g. is this approach reasonable?  are the policy changes okay?
etc.) I felt the advantages of sharing this code at such an early stage
outweighed the risks.

> I have uploaded certificate and key that I have generated here: 
> https://cloud.hawrylko.pl/s/ivHd7HZpuLIjQ88 there is also a signed
> bzImage that I am using.

Great, thank you.  I'll take a closer look.

> 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.
> 
> Thanks,
> Lukasz
> 

Re: [tboot-devel] [RFC] tboot: kernel signature verification

[Lukasz H. <luk...@li...>]

On Wed, 2019-12-04 at 14:33 +0000, Paul Moore (pmoore2) wrote:
> 
> Can you elaborate a bit more on what you mean by "the root of
> certificate"?  Alternatively, could you upload the kernel and signing
> certificate somewhere I could grab so I can play with it?
> 

Maybe I used wrong words, I am talking about pkcs1_search_signer
function and following lines:

  if (!asn1_blob_cmp(&entry->cert.serial, serial) &&
      !asn1_blob_cmp(&entry->cert.ca->subject, subject))

If I change them to

  if (!asn1_blob_cmp(&entry->cert.serial, serial) &&
      !asn1_blob_cmp(&entry->cert.subject, subject))

it will find my certificate. Could you please explain me why are you
using serial from root of entry and subject from sub-element? Is it
connected with certificate chain? What if there is just the simplest
possible certificate that is not signed by anybody?

I have uploaded certificate and key that I have generated here: 
https://cloud.hawrylko.pl/s/ivHd7HZpuLIjQ88 there is also a signed
bzImage that I am using.

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.

Thanks,
Lukasz

Re: [tboot-devel] [RFC] tboot: kernel signature verification

[Paul M. (pmoore2) <pm...@ci...>]

On Wed, 2019-12-04 at 14:33 +0000, Paul Moore (pmoore2) via tboot-devel
wrote:
> On Mon, 2019-12-02 at 14:09 +0100, Lukasz Hawrylko wrote:
> > If VLP is present under its own index (for TPM 2.0 it is
> > 0x01C10131),
> > tboot will not read LCP at all, so certificate will not be
> > available.
> > I
> > think that we should modify program flow, so even if VLP is present,
> > LCP
> > should be read to check if LCP_CUSTOM_ELEMENT_CERTS_UUID element is
> > there.
> 
> That sounds reasonable, let me see what I can do.

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.

-Paul

Re: [tboot-devel] [RFC] tboot: kernel signature verification

[Paul M. (pmoore2) <pm...@ci...>]

On Mon, 2019-12-02 at 14:09 +0100, Lukasz Hawrylko wrote:
> Hi Paul
> 
> I went through all steps and I was able to create LCP with
> certificated,
> VLP with TB_HTYPE_PECOFF and finally got platform booted with PCR 20
> extended by certificate hash (to be honest I didn't check if it is
> correct). So everything works, however I have few notes :)

No worries, thanks for giving it a test.  The code is still pretty
rough, so I expect there to be plenty of feedback :)

I guess what I'm most concerned about at this point are the changes to
the policy: both the new LCP certificate payload element as well as the
VLP/TB_HTYPE_PECOFF changes.  Do those seem reasonable?

> If VLP is present under its own index (for TPM 2.0 it is 0x01C10131),
> tboot will not read LCP at all, so certificate will not be available.
> I
> think that we should modify program flow, so even if VLP is present,
> LCP
> should be read to check if LCP_CUSTOM_ELEMENT_CERTS_UUID element is
> there.

That sounds reasonable, let me see what I can do.

> Still I can't verify signature of custom build kernel signed by my own
> key, I am trying to figure out what is wrong, but without luck. One
> thing that I found is a problem in pkcs1_search_signer
> function (pkcs1.c:101), it is comparing certificate subject, but not
> from the root of certificate.

Can you elaborate a bit more on what you mean by "the root of
certificate"?  Alternatively, could you upload the kernel and signing
certificate somewhere I could grab so I can play with it?

> I know that this is working fine with
> Fedora's certificate, but I don't know if this is valid for every
> case. 
> With my simple certificate this was a first problem that I found. At
> least, you should check if pointer to next element in chain is not
> NULL.

[tboot-devel] leveraging native secure boot from chip vendors

[Mat <alt...@gm...>]

e.g., Qualcomm does support native secure boot. Any pros/cons using such
native solutions versus other solutions?

Re: [tboot-devel] [RFC] tboot: kernel signature verification

[Lukasz H. <luk...@li...>]

Hi Paul

I went through all steps and I was able to create LCP with certificated,
VLP with TB_HTYPE_PECOFF and finally got platform booted with PCR 20
extended by certificate hash (to be honest I didn't check if it is
correct). So everything works, however I have few notes :)

If VLP is present under its own index (for TPM 2.0 it is 0x01C10131),
tboot will not read LCP at all, so certificate will not be available. I
think that we should modify program flow, so even if VLP is present, LCP
should be read to check if LCP_CUSTOM_ELEMENT_CERTS_UUID element is
there.

Still I can't verify signature of custom build kernel signed by my own
key, I am trying to figure out what is wrong, but without luck. One
thing that I found is a problem in pkcs1_search_signer
function (pkcs1.c:101), it is comparing certificate subject, but not
from the root of certificate. I know that this is working fine with
Fedora's certificate, but I don't know if this is valid for every case. 
With my simple certificate this was a first problem that I found. At
least, you should check if pointer to next element in chain is not NULL.

Thanks,
Lukasz

On Wed, 2019-11-20 at 23:05 +0000, Paul Moore (pmoore2) via tboot-devel
wrote:
> On Fri, 2019-10-18 at 13:27 +0000, Paul Moore (pmoore2) via tboot-devel
> wrote:
> > On Thu, 2019-09-19 at 15:39 +0000, Paul Moore (pmoore2) via
> > tboot-devel wrote:
> > > Hello,
> > > 
> > > I've been working on adding PECOFF/kernel signature verification to
> > > tboot ...
> 
> Hello everyone,
> 
> I just pushed another update to my git repository under the working-
> txtsig branch:
> 
> * 
> https://github.com/pcmoore/misc-tboot/tree/working-txtsig
> 
> 
> This update is notable in that it adds the missing policy support; no
> longer is the Fedora CA built into the tboot binary, verification
> certificates should be included in the LCP and the tboot VLP specifies
> which modules are subject to signature verification.  While there is
> still work to be done, I believe the code is now feature complete (or
> very close to it).  I would appreciate sanity checks on my approach,
> especially when it comes to the policy changes.
> 
> The commit descriptions have additional information, but in order to
> include certificates in the LCP, you would do the following:
> 
>  # lcp2_crtpolelt --create \
>      --type custom --uuid certificates test.der \
>      --out test.elt
> 
> ... in this case test.der is a DER encoded X509 certificate; multiple
> certificates may be concatenated together into the file, tboot will load
> each certificate.  Once the policy ELT has been created, it can be
> included in the LCP just as you would any other ELT module.
> 
> Once you have created a certificate ELT, you need to tell the tboot VLP
> to perform PECOFF signature verification on the kernel module; you can
> do that with the following command(s):
> 
>   # tb_polgen --create --type nonfatal test.vlp
>   # tb_polgen --add --num 0 --pcr 20 --hash pecoff test.vlp
>   # tb_polgen --show test.vlp
>   policy:
>          version: 2
>          policy_type: TB_POLTYPE_CONT_NON_FATAL
>          hash_alg: TB_HALG_SHA1
>          policy_control: 00000001 (EXTEND_PCR17)
>          num_entries: 1
>          policy entry[0]:
>                  mod_num: 0
>                  pcr: 20
>                  hash_type: TB_HTYPE_PECOFF
>                  num_hashes: 0
> 
> ... the pecoff/TB_HTYPE_PECOFF hash type instructs tboot to perform
> PECOFF signature verification on the given module.  When selected, the
> digest of the trusted root for the signing authority will be extended
> into the given PCR, which happens to be PCR 20 in the example above.  As
> a point of clarification, the "trusted root" is not necessarily the root
> CA of the signature chain, but rather the "nearest" certificate that was
> loaded from the LCP which is part of the signature chain.  This should
> provide for the most flexibility while preserving a signature root of
> trust in the LCP/TPM.
> 
> Comments and feedback on this approach are encouraged!
> 
> -Paul
> 
> 
> _______________________________________________
> tboot-devel mailing list
> tbo...@li...
> 
> https://lists.sourceforge.net/lists/listinfo/tboot-devel
> 
> 

[tboot-devel] unsubscribe

[Scheie, P. M <Pet...@gd...>]

unsubscribe

Re: [tboot-devel] [RFC] tboot: kernel signature verification

[Lukasz H. <luk...@li...>]

Hi Paul

Great news, I will check in the next week how it works and come back
with feedback.

Thanks,
Lukasz

On Wed, 2019-11-20 at 23:05 +0000, Paul Moore (pmoore2) via tboot-devel
wrote:
> On Fri, 2019-10-18 at 13:27 +0000, Paul Moore (pmoore2) via tboot-devel
> wrote:
> > On Thu, 2019-09-19 at 15:39 +0000, Paul Moore (pmoore2) via
> > tboot-devel wrote:
> > > Hello,
> > > 
> > > I've been working on adding PECOFF/kernel signature verification to
> > > tboot ...
> 
> Hello everyone,
> 
> I just pushed another update to my git repository under the working-
> txtsig branch:
> 
> * 
> https://github.com/pcmoore/misc-tboot/tree/working-txtsig
> 
> 
> This update is notable in that it adds the missing policy support; no
> longer is the Fedora CA built into the tboot binary, verification
> certificates should be included in the LCP and the tboot VLP specifies
> which modules are subject to signature verification.  While there is
> still work to be done, I believe the code is now feature complete (or
> very close to it).  I would appreciate sanity checks on my approach,
> especially when it comes to the policy changes.
> 
> The commit descriptions have additional information, but in order to
> include certificates in the LCP, you would do the following:
> 
>  # lcp2_crtpolelt --create \
>      --type custom --uuid certificates test.der \
>      --out test.elt
> 
> ... in this case test.der is a DER encoded X509 certificate; multiple
> certificates may be concatenated together into the file, tboot will load
> each certificate.  Once the policy ELT has been created, it can be
> included in the LCP just as you would any other ELT module.
> 
> Once you have created a certificate ELT, you need to tell the tboot VLP
> to perform PECOFF signature verification on the kernel module; you can
> do that with the following command(s):
> 
>   # tb_polgen --create --type nonfatal test.vlp
>   # tb_polgen --add --num 0 --pcr 20 --hash pecoff test.vlp
>   # tb_polgen --show test.vlp
>   policy:
>          version: 2
>          policy_type: TB_POLTYPE_CONT_NON_FATAL
>          hash_alg: TB_HALG_SHA1
>          policy_control: 00000001 (EXTEND_PCR17)
>          num_entries: 1
>          policy entry[0]:
>                  mod_num: 0
>                  pcr: 20
>                  hash_type: TB_HTYPE_PECOFF
>                  num_hashes: 0
> 
> ... the pecoff/TB_HTYPE_PECOFF hash type instructs tboot to perform
> PECOFF signature verification on the given module.  When selected, the
> digest of the trusted root for the signing authority will be extended
> into the given PCR, which happens to be PCR 20 in the example above.  As
> a point of clarification, the "trusted root" is not necessarily the root
> CA of the signature chain, but rather the "nearest" certificate that was
> loaded from the LCP which is part of the signature chain.  This should
> provide for the most flexibility while preserving a signature root of
> trust in the LCP/TPM.
> 
> Comments and feedback on this approach are encouraged!
> 
> -Paul
> 
> 
> _______________________________________________
> tboot-devel mailing list
> tbo...@li...
> 
> https://lists.sourceforge.net/lists/listinfo/tboot-devel
> 
> 

[tboot-devel] unsubscribe

[Scheie, P. M <Pet...@gd...>]

unsubscribe

Re: [tboot-devel] [RFC] tboot: kernel signature verification

[Paul M. (pmoore2) <pm...@ci...>]

On Fri, 2019-10-18 at 13:27 +0000, Paul Moore (pmoore2) via tboot-devel
wrote:
> On Thu, 2019-09-19 at 15:39 +0000, Paul Moore (pmoore2) via
> tboot-devel wrote:
> > Hello,
> > 
> > I've been working on adding PECOFF/kernel signature verification to
> > tboot ...

Hello everyone,

I just pushed another update to my git repository under the working-
txtsig branch:

* https://github.com/pcmoore/misc-tboot/tree/working-txtsig

This update is notable in that it adds the missing policy support; no
longer is the Fedora CA built into the tboot binary, verification
certificates should be included in the LCP and the tboot VLP specifies
which modules are subject to signature verification.  While there is
still work to be done, I believe the code is now feature complete (or
very close to it).  I would appreciate sanity checks on my approach,
especially when it comes to the policy changes.

The commit descriptions have additional information, but in order to
include certificates in the LCP, you would do the following:

 # lcp2_crtpolelt --create \
     --type custom --uuid certificates test.der \
     --out test.elt

... in this case test.der is a DER encoded X509 certificate; multiple
certificates may be concatenated together into the file, tboot will load
each certificate.  Once the policy ELT has been created, it can be
included in the LCP just as you would any other ELT module.

Once you have created a certificate ELT, you need to tell the tboot VLP
to perform PECOFF signature verification on the kernel module; you can
do that with the following command(s):

  # tb_polgen --create --type nonfatal test.vlp
  # tb_polgen --add --num 0 --pcr 20 --hash pecoff test.vlp
  # tb_polgen --show test.vlp
  policy:
         version: 2
         policy_type: TB_POLTYPE_CONT_NON_FATAL
         hash_alg: TB_HALG_SHA1
         policy_control: 00000001 (EXTEND_PCR17)
         num_entries: 1
         policy entry[0]:
                 mod_num: 0
                 pcr: 20
                 hash_type: TB_HTYPE_PECOFF
                 num_hashes: 0

... the pecoff/TB_HTYPE_PECOFF hash type instructs tboot to perform
PECOFF signature verification on the given module.  When selected, the
digest of the trusted root for the signing authority will be extended
into the given PCR, which happens to be PCR 20 in the example above.  As
a point of clarification, the "trusted root" is not necessarily the root
CA of the signature chain, but rather the "nearest" certificate that was
loaded from the LCP which is part of the signature chain.  This should
provide for the most flexibility while preserving a signature root of
trust in the LCP/TPM.

Comments and feedback on this approach are encouraged!

-Paul

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

[Dr. G. <gr...@en...>]

On Fri, Nov 15, 2019 at 07:40:58PM +0000, Paul Moore (pmoore2) via tboot-devel wrote:

Hi, I hope the week is starting well for everyone.

> Thanks Lukasz.  I realize that might be a difficult discussion
> internally, but I think it is the right thing to do at this point in
> time.

Hopefully, if relevancy is the metric, it shouldn't be too hard to
sell the concept of C based command-line tools.

There are only a handful of people working on this technology.  Within
that group I would reason, with a high degree of probability, that we
all prefer working with command-line tools and we are all universally
working with C based toolchains.

We did a proof of concept validation for a partner on TPM2 Broadwell
and Skylake based systems that we took as far as getting Linux to do a
trusted boot.  We put that work on the shelf without doing any
significant policy work, in part, because we didn't have the cycles to
deal with implications of the Python based tools.

We had done a lot of partner work on TPM1/TBOOT based embedded systems
and all of our scripting and workflow were command-line and C tool
based.

Hopefully another useful data point.

Best wishes for a productive week.

Dr. Greg

As always,
Dr. Greg Wettstein, Ph.D, Worker
IDfusion, LLC               SGX secured infrastructure and
4206 N. 19th Ave.           autonomously self-defensive platforms.
Fargo, ND  58102
PH: 701-281-1686            EMAIL: gr...@id...
------------------------------------------------------------------------------
"Nullum magnum ingenium sine mixtura dementiae fuit."
        (There is no great genius without some touch of madness.)
                                -- Seneca

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

[Paul M. (pmoore2) <pm...@ci...>]

Thanks Lukasz.  I realize that might be a difficult discussion
internally, but I think it is the right thing to do at this point in
time.

On Fri, 2019-11-15 at 15:07 +0100, Lukasz Hawrylko wrote:
> To be honest I don't know the history of lcp-gen2, personally I prefer
> CLI tools too, so I understand your point. I thought that migration to
> GUI tool was requested by TBOOT users. I going to start internal
> discussion who is using lcp-gen2, maybe we should take a step back and
> instead of developing new tool that nobody is going to use, continue
> support for lcptools-v2.
> 
> 
> On Wed, 2019-11-13 at 17:15 +0000, Tra...@de... wrote:
> > > -----Original Message-----
> > > From: Lukasz Hawrylko <
> > > luk...@li...
> > > Sent: Wednesday, November 13, 2019 08:24
> > > To: Gilbert, Travis; 
> > > pm...@ci...
> > > 
> > > Cc: 
> > > tbo...@li...
> > > 
> > > 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, 
> > > 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.

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

[Lukasz H. <luk...@li...>]

To be honest I don't know the history of lcp-gen2, personally I prefer
CLI tools too, so I understand your point. I thought that migration to
GUI tool was requested by TBOOT users. I going to start internal
discussion who is using lcp-gen2, maybe we should take a step back and
instead of developing new tool that nobody is going to use, continue
support for lcptools-v2.


On Wed, 2019-11-13 at 17:15 +0000, Tra...@de... wrote:
> > -----Original Message-----
> > From: Lukasz Hawrylko <
> > luk...@li...
> > >
> > Sent: Wednesday, November 13, 2019 08:24
> > To: Gilbert, Travis; 
> > pm...@ci...
> > 
> > Cc: 
> > tbo...@li...
> > 
> > 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, 
> > 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.
> 
> 

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

[Paul M. (pmoore2) <pm...@ci...>]

On Wed, 2019-11-13 at 17:17 +0000, Tra...@de... wrote:
> > -----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 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?

That is the current approach, yes, but I consider it very much up for
discussion/review.

Essentially you dump a bundle of DER encoded certificates into a policy
element and mark it with the newly specified UUID and after tboot has
entered into the TXT protected state it imports those certificates into
the cert DB as "trusted" which allows them to act as a root of trust for
the PECOFF signature verification.  This is actually working now, but I
want to sort out the VLP details before updating the GitHub repo.

The VLP changes are still a work in progress, but my current approach is
to introduce a new hash type (e.g. TB_HTYPE_PECOFF) which would be an
indication to tboot to perform PECOFF signature verification (using the
previously imported trusted certificate payload) instead of the
traditional digest verification.  Not only does this preserve the VLP
format, but it allows us to integrate with the rest of the VLP and
leverage all of the existing policy functionality such as configurable
PCR extension.  Similar to the certificate ELT payload, it *should*
result in minimal changes to the tooling, most of the changes will be
in tboot itself.

As soon as I have the VLP changes working I'll update my GH repo and
post an update to the list, but comments on the above approach are
always welcome.

-Paul

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.
> > >

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

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

> -----Original Message-----
> From: Lukasz Hawrylko <luk...@li...>
> Sent: Wednesday, November 13, 2019 08:24
> To: Gilbert, Travis; pm...@ci...
> Cc: tbo...@li...
> 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, 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.
> >

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

[Paul M. (pmoore2) <pm...@ci...>]

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.

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).  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.
> > 

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

[Lukasz H. <luk...@li...>]

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.
> 

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: 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.

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

[Paul M. (pmoore2) <pm...@ci...>]

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
 

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

[Lukasz H. <luk...@li...>]

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.

Thanks,
Lukasz

On Thu, 2019-11-07 at 21:09 +0000, Paul Moore (pmoore2) via tboot-devel
wrote:
> On Wed, 2019-11-06 at 20:12 +0000, 
> Tra...@de...
>  wrote:
> > > -----Original Message-----
> > > From: Paul Moore (pmoore2) <
> > > pm...@ci...
> > > >
> > > Sent: Tuesday, November 5, 2019 19:28
> > > To: Gilbert, Travis
> > > Cc: 
> > > tbo...@li...
> > > 
> > > Subject: Re: Creating a TXT/tboot policy suitable for a modern
> > > system with
> > > TXT+TPM2
> > > 
> > > On Tue, 2019-11-05 at 23:02 +0000, 
> > > Tra...@de...
> > >  wrote:
> > > > > -----Original Message-----
> > > > > From: Paul Moore (pmoore2) via tboot-devel <tboot-
> > > > > de...@li...
> > > > > >
> > > > > Sent: Tuesday, November 5, 2019 16:50
> > > > > To: 
> > > > > luk...@li...
> > > > > ;
> > > > > tbo...@li...
> > > > > 
> > > > > Subject: [tboot-devel] Creating a TXT/tboot policy suitable for
> > > > > a
> > > > > modern system with TXT+TPM2
> > > > > 
> > > > > 
> > > > > 
> > > > > Hi Lukasz, others,
> > > > > 
> > > > > I'm in the process of working on the TXT/sig extensions to the
> > > > > LCP
> > > > > but I'm running into problems using the tboot tools to create a
> > > > > working LCP as a baseline.  Simply put, the instructions I've
> > > > > been
> > > > > able to find either in the sources, the mailing list archives,
> > > > > or
> > > > > through Google searches do not produce a working LCP on my test
> > > > > system.  The tools/arguments are either wrong, or the resulting
> > > > > LCP
> > > > > is bogus.
> > > > 
> > > > I had to patch lcptools-v2 because I found the same problem.
> > > > Nothing
> > > > would produce a good LCP.
> > > > 
> > > > > Before I start hacking away at the tools to get them to create a
> > > > > functional LCP that tboot understands, does anyone have a
> > > > > working
> > > > > how-to for creating a LCP using the current sources?
> > > > 
> > > > When I patched lcptools-v2, I added a simple how-to for an MLE
> > > > LCP,
> > > > it's in the mailing list archives at the link below. If you need
> > > > more,
> > > > I have a few other examples.
> > > > 
> > > > https://sourceforge.net/p/tboot/mailman/message/35976955/
> > > > 
> > > 
> > > Thanks Travis, that got me going in the right direction; I needed to
> > > add a
> > > tboot policy element to make my system happy, but that was a trivial
> > > addition to your instructions above.
> > > 
> > > If you're willing to share your other examples, I'd love to see
> > > them, and I'm
> > > sure others would as well.
> > > 
> > > Thanks again.
> > 
> > I've got about 20 some of which are negative test cases. They're bash
> > scripts. I've stripped out the beginning shell line to make it more
> > email handler friendly. #9 is actually split into 5 different tests
> > signing various other policies that were previously unsigned. They
> > were designed to be run in order as some later tests rely on the
> > outputs of previous tests. I've included #3 and one of #9. Let me know
> > if you have interest in any of the others. You don't have to take
> > ownership or define the index every time, but keeping it in the script
> > didn't cause us any issues. We could just copy some of the
> > intermediate files and keep things simple when running tests out of
> > order on multiple machines.
> > 
> > TXT - Scenario#1, Single MLE element and Unsigned Policy
> > TXT - Scenario#2, Three MLE elements and Unsigned LCP
> > TXT - Scenario#3, One PCONF element and Unsigned LCP
> > TXT - Scenario#4, Two PCONF elements and Unsigned LCP
> > TXT - Scenario#5, MLE, PCONF list Unsigned
> > TXT - Scenario#6, SINIT Revocation (Negative Testing)
> > TXT - Scenario#7, MLE Mismatch 1 - wrong hash file (Negative Testing)
> > TXT - Scenario#8, PCONF mismatch (Negative Testing)
> > TXT - Scenario#9, Signed policies with 2048 keys
> > TXT - Scenario#10, Signed policy with 1024 key
> > TXT - Scenario#11, Signed policy with 3072 key
> > TXT - Scenario#12: signed policy with invalid key size (2000)
> > TXT - Scenario#13 Input Validation, signed policy with invalid key
> > size (512)
> > TXT - Scenario#14, signed policy with invalid key size (4096)
> > TXT - Scenario#15, MLE Mismatch - change in boot parameters (Negative
> > Testing)
> > 
> > <3>
> > cd /boot
> > tpm2_takeownership -o new -e new -l new
> > tpm2_nvdefine -x 0x1c10106 -a 0x40000001 -P new -s 70 -t 0x204000A
> > 
> > #TXT - Scenario#3, One PCONF element and Unsigned LCP
> > tpm2_listpcrs -g 0x0B -o 1pcrs
> > truncate -s 32 1pcrs #only select PCR0 for the policy
> > lcp2_crtpolelt --create --type pconf --out 1pconf.elt 1pcrs
> > lcp2_crtpollist --create --out lists3_unsig.lst 1pconf.elt
> > lcp2_crtpol --create --type list --pol lists3.pol --alg sha256 --sign
> > 0x0A --data lists3.data lists3_unsig.lst
> > tpm2_nvwrite -x 0x1c10106 -a 0x40000001 -P new -f lists3.pol
> > echo TBOOT_POLICY_DATA_FILE="lists3.data" > /etc/default/grub-tboot
> > grub2-mkconfig -o /boot/grub2/grub.cfg
> > </3>
> > 
> > <9>
> > cd /boot
> > tpm2_takeownership -o new -e new -l new
> > tpm2_nvdefine -x 0x1c10106 -a 0x40000001 -P new -s 70 -t 0x204000A
> > 
> > #TXT - Scenario#9, Signed policies with 2048 keys
> > openssl genrsa -out privkey.pem 2048
> > openssl rsa -pubout -in privkey.pem -out pubkey.pem
> > cp lists1_unsig.lst lists1_sig.lst
> > lcp2_crtpollist --sign --pub pubkey.pem --priv privkey.pem --out
> > lists1_sig.lst
> > lcp2_crtpol --create --type list --alg sha256 --sign 0x0A --pol
> > lists9a.pol --data lists9a.data lists1_sig.lst
> > tpm2_nvwrite -x 0x1c10106 -a 0x40000001 -P new -f lists9a.pol
> > echo GRUB_TBOOT_POLICY_DATA="lists9a.data" > /etc/default/grub-tboot
> > grub2-mkconfig -o /boot/grub2/grub.cfg
> > </9>
> 
> Thanks Travis!
> 
> 
> _______________________________________________
> tboot-devel mailing list
> tbo...@li...
> 
> https://lists.sourceforge.net/lists/listinfo/tboot-devel
> 
> 

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

[Paul M. (pmoore2) <pm...@ci...>]

On Wed, 2019-11-06 at 20:12 +0000, Tra...@de... wrote:
> > -----Original Message-----
> > From: Paul Moore (pmoore2) <pm...@ci...>
> > Sent: Tuesday, November 5, 2019 19:28
> > To: Gilbert, Travis
> > Cc: tbo...@li...
> > Subject: Re: Creating a TXT/tboot policy suitable for a modern
> > system with
> > TXT+TPM2
> > 
> > On Tue, 2019-11-05 at 23:02 +0000, Tra...@de... wrote:
> > > > -----Original Message-----
> > > > From: Paul Moore (pmoore2) via tboot-devel <tboot-
> > > > de...@li...>
> > > > Sent: Tuesday, November 5, 2019 16:50
> > > > To: luk...@li...;
> > > > tbo...@li...
> > > > Subject: [tboot-devel] Creating a TXT/tboot policy suitable for
> > > > a
> > > > modern system with TXT+TPM2
> > > > 
> > > > 
> > > > 
> > > > Hi Lukasz, others,
> > > > 
> > > > I'm in the process of working on the TXT/sig extensions to the
> > > > LCP
> > > > but I'm running into problems using the tboot tools to create a
> > > > working LCP as a baseline.  Simply put, the instructions I've
> > > > been
> > > > able to find either in the sources, the mailing list archives,
> > > > or
> > > > through Google searches do not produce a working LCP on my test
> > > > system.  The tools/arguments are either wrong, or the resulting
> > > > LCP
> > > > is bogus.
> > > 
> > > I had to patch lcptools-v2 because I found the same problem.
> > > Nothing
> > > would produce a good LCP.
> > > 
> > > > Before I start hacking away at the tools to get them to create a
> > > > functional LCP that tboot understands, does anyone have a
> > > > working
> > > > how-to for creating a LCP using the current sources?
> > > 
> > > When I patched lcptools-v2, I added a simple how-to for an MLE
> > > LCP,
> > > it's in the mailing list archives at the link below. If you need
> > > more,
> > > I have a few other examples.
> > > 
> > > https://sourceforge.net/p/tboot/mailman/message/35976955/
> > 
> > Thanks Travis, that got me going in the right direction; I needed to
> > add a
> > tboot policy element to make my system happy, but that was a trivial
> > addition to your instructions above.
> > 
> > If you're willing to share your other examples, I'd love to see
> > them, and I'm
> > sure others would as well.
> > 
> > Thanks again.
> 
> I've got about 20 some of which are negative test cases. They're bash
> scripts. I've stripped out the beginning shell line to make it more
> email handler friendly. #9 is actually split into 5 different tests
> signing various other policies that were previously unsigned. They
> were designed to be run in order as some later tests rely on the
> outputs of previous tests. I've included #3 and one of #9. Let me know
> if you have interest in any of the others. You don't have to take
> ownership or define the index every time, but keeping it in the script
> didn't cause us any issues. We could just copy some of the
> intermediate files and keep things simple when running tests out of
> order on multiple machines.
> 
> TXT - Scenario#1, Single MLE element and Unsigned Policy
> TXT - Scenario#2, Three MLE elements and Unsigned LCP
> TXT - Scenario#3, One PCONF element and Unsigned LCP
> TXT - Scenario#4, Two PCONF elements and Unsigned LCP
> TXT - Scenario#5, MLE, PCONF list Unsigned
> TXT - Scenario#6, SINIT Revocation (Negative Testing)
> TXT - Scenario#7, MLE Mismatch 1 - wrong hash file (Negative Testing)
> TXT - Scenario#8, PCONF mismatch (Negative Testing)
> TXT - Scenario#9, Signed policies with 2048 keys
> TXT - Scenario#10, Signed policy with 1024 key
> TXT - Scenario#11, Signed policy with 3072 key
> TXT - Scenario#12: signed policy with invalid key size (2000)
> TXT - Scenario#13 Input Validation, signed policy with invalid key
> size (512)
> TXT - Scenario#14, signed policy with invalid key size (4096)
> TXT - Scenario#15, MLE Mismatch - change in boot parameters (Negative
> Testing)
> 
> <3>
> cd /boot
> tpm2_takeownership -o new -e new -l new
> tpm2_nvdefine -x 0x1c10106 -a 0x40000001 -P new -s 70 -t 0x204000A
> 
> #TXT - Scenario#3, One PCONF element and Unsigned LCP
> tpm2_listpcrs -g 0x0B -o 1pcrs
> truncate -s 32 1pcrs #only select PCR0 for the policy
> lcp2_crtpolelt --create --type pconf --out 1pconf.elt 1pcrs
> lcp2_crtpollist --create --out lists3_unsig.lst 1pconf.elt
> lcp2_crtpol --create --type list --pol lists3.pol --alg sha256 --sign
> 0x0A --data lists3.data lists3_unsig.lst
> tpm2_nvwrite -x 0x1c10106 -a 0x40000001 -P new -f lists3.pol
> echo TBOOT_POLICY_DATA_FILE="lists3.data" > /etc/default/grub-tboot
> grub2-mkconfig -o /boot/grub2/grub.cfg
> </3>
> 
> <9>
> cd /boot
> tpm2_takeownership -o new -e new -l new
> tpm2_nvdefine -x 0x1c10106 -a 0x40000001 -P new -s 70 -t 0x204000A
> 
> #TXT - Scenario#9, Signed policies with 2048 keys
> openssl genrsa -out privkey.pem 2048
> openssl rsa -pubout -in privkey.pem -out pubkey.pem
> cp lists1_unsig.lst lists1_sig.lst
> lcp2_crtpollist --sign --pub pubkey.pem --priv privkey.pem --out
> lists1_sig.lst
> lcp2_crtpol --create --type list --alg sha256 --sign 0x0A --pol
> lists9a.pol --data lists9a.data lists1_sig.lst
> tpm2_nvwrite -x 0x1c10106 -a 0x40000001 -P new -f lists9a.pol
> echo GRUB_TBOOT_POLICY_DATA="lists9a.data" > /etc/default/grub-tboot
> grub2-mkconfig -o /boot/grub2/grub.cfg
> </9>

Thanks Travis!

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: Tuesday, November 5, 2019 19:28
> To: Gilbert, Travis
> Cc: tbo...@li...
> Subject: Re: Creating a TXT/tboot policy suitable for a modern system with
> TXT+TPM2
> 
> On Tue, 2019-11-05 at 23:02 +0000, Tra...@de... wrote:
> > > -----Original Message-----
> > > From: Paul Moore (pmoore2) via tboot-devel <tboot-
> > > de...@li...>
> > > Sent: Tuesday, November 5, 2019 16:50
> > > To: luk...@li...;
> > > tbo...@li...
> > > Subject: [tboot-devel] Creating a TXT/tboot policy suitable for a
> > > modern system with TXT+TPM2
> > >
> > >
> > >
> > > Hi Lukasz, others,
> > >
> > > I'm in the process of working on the TXT/sig extensions to the LCP
> > > but I'm running into problems using the tboot tools to create a
> > > working LCP as a baseline.  Simply put, the instructions I've been
> > > able to find either in the sources, the mailing list archives, or
> > > through Google searches do not produce a working LCP on my test
> > > system.  The tools/arguments are either wrong, or the resulting LCP
> > > is bogus.
> >
> > I had to patch lcptools-v2 because I found the same problem. Nothing
> > would produce a good LCP.
> >
> > > Before I start hacking away at the tools to get them to create a
> > > functional LCP that tboot understands, does anyone have a working
> > > how-to for creating a LCP using the current sources?
> >
> > When I patched lcptools-v2, I added a simple how-to for an MLE LCP,
> > it's in the mailing list archives at the link below. If you need more,
> > I have a few other examples.
> >
> > https://sourceforge.net/p/tboot/mailman/message/35976955/
> 
> Thanks Travis, that got me going in the right direction; I needed to add a
> tboot policy element to make my system happy, but that was a trivial
> addition to your instructions above.
> 
> If you're willing to share your other examples, I'd love to see them, and I'm
> sure others would as well.
> 
> Thanks again.

I've got about 20 some of which are negative test cases. They're bash scripts. I've stripped out the beginning shell line to make it more email handler friendly. #9 is actually split into 5 different tests signing various other policies that were previously unsigned. They were designed to be run in order as some later tests rely on the outputs of previous tests. I've included #3 and one of #9. Let me know if you have interest in any of the others. You don't have to take ownership or define the index every time, but keeping it in the script didn't cause us any issues. We could just copy some of the intermediate files and keep things simple when running tests out of order on multiple machines.

TXT - Scenario#1, Single MLE element and Unsigned Policy
TXT - Scenario#2, Three MLE elements and Unsigned LCP
TXT - Scenario#3, One PCONF element and Unsigned LCP
TXT - Scenario#4, Two PCONF elements and Unsigned LCP
TXT - Scenario#5, MLE, PCONF list Unsigned
TXT - Scenario#6, SINIT Revocation (Negative Testing)
TXT - Scenario#7, MLE Mismatch 1 - wrong hash file (Negative Testing)
TXT - Scenario#8, PCONF mismatch (Negative Testing)
TXT - Scenario#9, Signed policies with 2048 keys
TXT - Scenario#10, Signed policy with 1024 key
TXT - Scenario#11, Signed policy with 3072 key
TXT - Scenario#12: signed policy with invalid key size (2000)
TXT - Scenario#13 Input Validation, signed policy with invalid key size (512)
TXT - Scenario#14, signed policy with invalid key size (4096)
TXT - Scenario#15, MLE Mismatch - change in boot parameters (Negative Testing)

<3>
cd /boot
tpm2_takeownership -o new -e new -l new
tpm2_nvdefine -x 0x1c10106 -a 0x40000001 -P new -s 70 -t 0x204000A

#TXT - Scenario#3, One PCONF element and Unsigned LCP
tpm2_listpcrs -g 0x0B -o 1pcrs
truncate -s 32 1pcrs #only select PCR0 for the policy
lcp2_crtpolelt --create --type pconf --out 1pconf.elt 1pcrs
lcp2_crtpollist --create --out lists3_unsig.lst 1pconf.elt
lcp2_crtpol --create --type list --pol lists3.pol --alg sha256 --sign 0x0A --data lists3.data lists3_unsig.lst
tpm2_nvwrite -x 0x1c10106 -a 0x40000001 -P new -f lists3.pol
echo TBOOT_POLICY_DATA_FILE="lists3.data" > /etc/default/grub-tboot
grub2-mkconfig -o /boot/grub2/grub.cfg
</3>

<9>
cd /boot
tpm2_takeownership -o new -e new -l new
tpm2_nvdefine -x 0x1c10106 -a 0x40000001 -P new -s 70 -t 0x204000A

#TXT - Scenario#9, Signed policies with 2048 keys
openssl genrsa -out privkey.pem 2048
openssl rsa -pubout -in privkey.pem -out pubkey.pem
cp lists1_unsig.lst lists1_sig.lst
lcp2_crtpollist --sign --pub pubkey.pem --priv privkey.pem --out lists1_sig.lst
lcp2_crtpol --create --type list --alg sha256 --sign 0x0A --pol lists9a.pol --data lists9a.data lists1_sig.lst
tpm2_nvwrite -x 0x1c10106 -a 0x40000001 -P new -f lists9a.pol
echo GRUB_TBOOT_POLICY_DATA="lists9a.data" > /etc/default/grub-tboot
grub2-mkconfig -o /boot/grub2/grub.cfg
</9>

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

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

> -----Original Message-----
> From: Paul Moore (pmoore2) via tboot-devel <tboot-
> de...@li...>
> Sent: Tuesday, November 5, 2019 16:50
> To: luk...@li...; tbo...@li...
> Subject: [tboot-devel] Creating a TXT/tboot policy suitable for a modern
> system with TXT+TPM2
> 
> 
> 
> Hi Lukasz, others,
> 
> I'm in the process of working on the TXT/sig extensions to the LCP but I'm
> running into problems using the tboot tools to create a working LCP as a
> baseline.  Simply put, the instructions I've been able to find either in the
> sources, the mailing list archives, or through Google searches do not produce
> a working LCP on my test system.  The tools/arguments are either wrong, or
> the resulting LCP is bogus.

I had to patch lcptools-v2 because I found the same problem. Nothing would produce a good LCP.

> Before I start hacking away at the tools to get them to create a functional LCP
> that tboot understands, does anyone have a working how-to for creating a
> LCP using the current sources?

When I patched lcptools-v2, I added a simple how-to for an MLE LCP, it's in the mailing list archives at the link below. If you need more, I have a few other examples.

https://sourceforge.net/p/tboot/mailman/message/35976955/