tboot-devel — Developer support

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

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

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.

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

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

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.

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?

Thanks,
-Paul

[tboot-devel] unsubscribe

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

unsubscribe

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

[Paul M. <pa...@pa...>]

Hi Lukasz,

That's great news, I'll look forward too meeting with you next week! I'll follow up with you off-list with some contact information.

--
paul moore
www.paul-moore.com
On October 24, 2019 9:19:52 AM Lukasz Hawrylko <luk...@li...> wrote:

> Hi
>
> I will be on LSS EU, I will catch you after your presentation for a
> short (or not short) conversation.
>
> Thanks,
> Lukasz
>
> 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 and now that I have a rough working prototype I wanted to bring
>> > it to the list to see if this is something the tboot community would
>> > be interested in eventually merging (once the work is more complete
>> > and polished).
>> >
>> > The patchset is quite large, mostly due to the inclusion of
>> > libtomcrypt and libtomfastmath to the tboot repository, so I'm going
>> > to refrain from spamming the list with the full patchset at this early
>> > stage.  The current patchset can be found on GitHub at the URL below
>> > (look in the "working-txtsig" branch):
>> >
>> > *
>> > https://github.com/pcmoore/misc-tboot/tree/working-txtsig
>> >
>> >
>>
>> I've updated the working-txtsig branch with a number of fixes relating
>> to the ASN.1/PKCS parsing code as well as improved signing/hash
>> algorithm support (previously limited to SHA256) and the ability to
>> verify kernels using variable length certificate chains (previously
>> limited to the immediate signer).  Work on adding certificate support to
>> the tboot launch control policy is ongoing (it's the next major work
>> item), but the prototype contains a hard coded Fedora CA which should be
>> able to verify any modern Fedora kernel.  Just as before, if you have
>> any questions, concerns, or feedback please get in touch on-list or
>> privately.
>>
>> I'll be giving an updated presentation on this effort at the Linux
>> Security Summit EU later this month, if you are in the area please stop
>> by and introduce yourself - I'd love to talk about TXT/tboot!
>>
>> https://events19.linuxfoundation.org/events/linux-security-summit-europe-2019
>>
>>
>> Thanks,
>> -Paul
>>
>>
>> _______________________________________________
>> tboot-devel mailing list
>> tbo...@li...
>>
>> https://lists.sourceforge.net/lists/listinfo/tboot-devel
>>
>>
>
>
>
> _______________________________________________
> tboot-devel mailing list
> tbo...@li...
> https://lists.sourceforge.net/lists/listinfo/tboot-devel

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

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

Hi

I will be on LSS EU, I will catch you after your presentation for a
short (or not short) conversation.

Thanks,
Lukasz

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 and now that I have a rough working prototype I wanted to bring
> > it to the list to see if this is something the tboot community would
> > be interested in eventually merging (once the work is more complete
> > and polished).
> > 
> > The patchset is quite large, mostly due to the inclusion of
> > libtomcrypt and libtomfastmath to the tboot repository, so I'm going
> > to refrain from spamming the list with the full patchset at this early
> > stage.  The current patchset can be found on GitHub at the URL below
> > (look in the "working-txtsig" branch):
> > 
> > * 
> > https://github.com/pcmoore/misc-tboot/tree/working-txtsig
> > 
> > 
> 
> I've updated the working-txtsig branch with a number of fixes relating
> to the ASN.1/PKCS parsing code as well as improved signing/hash
> algorithm support (previously limited to SHA256) and the ability to
> verify kernels using variable length certificate chains (previously
> limited to the immediate signer).  Work on adding certificate support to
> the tboot launch control policy is ongoing (it's the next major work
> item), but the prototype contains a hard coded Fedora CA which should be
> able to verify any modern Fedora kernel.  Just as before, if you have
> any questions, concerns, or feedback please get in touch on-list or
> privately.
> 
> I'll be giving an updated presentation on this effort at the Linux
> Security Summit EU later this month, if you are in the area please stop
> by and introduce yourself - I'd love to talk about TXT/tboot!
> 
> https://events19.linuxfoundation.org/events/linux-security-summit-europe-2019
> 
> 
> Thanks,
> -Paul
> 
> 
> _______________________________________________
> tboot-devel mailing list
> tbo...@li...
> 
> https://lists.sourceforge.net/lists/listinfo/tboot-devel
> 
> 

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

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

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 and now that I have a rough working prototype I wanted to bring
> it to the list to see if this is something the tboot community would
> be interested in eventually merging (once the work is more complete
> and polished).
> 
> The patchset is quite large, mostly due to the inclusion of
> libtomcrypt and libtomfastmath to the tboot repository, so I'm going
> to refrain from spamming the list with the full patchset at this early
> stage.  The current patchset can be found on GitHub at the URL below
> (look in the "working-txtsig" branch):
> 
> * https://github.com/pcmoore/misc-tboot/tree/working-txtsig
> 

I've updated the working-txtsig branch with a number of fixes relating
to the ASN.1/PKCS parsing code as well as improved signing/hash
algorithm support (previously limited to SHA256) and the ability to
verify kernels using variable length certificate chains (previously
limited to the immediate signer).  Work on adding certificate support to
the tboot launch control policy is ongoing (it's the next major work
item), but the prototype contains a hard coded Fedora CA which should be
able to verify any modern Fedora kernel.  Just as before, if you have
any questions, concerns, or feedback please get in touch on-list or
privately.

I'll be giving an updated presentation on this effort at the Linux
Security Summit EU later this month, if you are in the area please stop
by and introduce yourself - I'd love to talk about TXT/tboot!

https://events19.linuxfoundation.org/events/linux-security-summit-europe-2019

Thanks,
-Paul

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

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

Hi Lukasz,

I'm happy to join the internal discussion if you think it would be
helpful, although I do have some travel scheduled for later this month. 
Feel free to contact me off-list if you want to discuss timing.

Are you going to be at Linux Security Summit EU in France at the end of
October?

Thanks for taking the time to give the patch a quick look/test.  While
I've tested a handful of CentOS-7.x and Fedora 5.x kernels (NOTE:
CentOS-7.x and modern Fedora use a slightly different signature format),
I haven't tried signing my own kernel yet, but obviously that is
something that needs to work.  My guess is that Fedora/CentOS/RHEL uses
a technique similar to what you are using in your example so it *should*
work, but you've obviously hit a problem.  Since the code is still in
the "barely works" prototype stage I'm not going to worry about this too
much at the moment, but I will look into it before I submit the patchset
for inclusion, as opposed to the current RFC patchset.

FWIW, I'm currently working on getting certificate chains working.  The
code can now parse certificates into a crude certificate db, and I'm
currently sorting out the certificate signature verification.

Once I get the certificate chain support working, I plan to start
looking at the policy.  As we've previously discussed, hardcoding the
certificate into the tboot binary is an option of last resort.  Beyond
that, I think the options are wide open; I had always assumed that we
would likely need to store the certificate in the LCP portion of the
policy that is stored outside of the TPM.  So long as the policy can be
verified by a TPM based root of trust (which is what currently happens
with the LCP from what I can see) there shouldn't be a problem).

-Paul

On Tue, 2019-10-08 at 14:18 +0200, Lukasz Hawrylko wrote:
> Hi Paul
> 
> We are going to have internal discussion about this feature in two
> weeks, I have to prepare some presentation, so be prepare for
> questions
> in near future :)
> 
> I have built version with your patch, looks like verification is
> working
> with Fedora's kernel indeed. However I was not be able to verify
> kernel
> signed with my testing certificate, did you try that? TBOOT is hanging
> on:
> 
>     TBOOT: >>> DBG/SIG: mod[0], pkcs7 parsing
> 
> I guess that pkcs7_signeddata_parse can't read kernel signature, if
> you
> want to test it by yourself here are commands that I was using:
> 
>     openssl req -newkey rsa:4096 -nodes -keyout db.key -new -x509 \
>         -sha256 -days 3650 -subj "/CN=my Signature Database key/" \
>         -out db.crt
>     openssl x509 -outform DER -in db.crt -out db.cer
>     sbsign --key db.key --cert db.crt --output bzImage_signed bzImage
> 
> Adding certificate to VLP has one major disadvantage - VLP is stored
> in
> TPM NV that has very limited space. Putting ~1kB certificate there is
> in
> my opinion bad idea. I would suggest to implement the same mechanism
> as
> we already have for LCP. Certificate will be stored on disk and will
> be
> passed to TBOOT using multiboot2 protocol. In VLP there will be only
> hash of that file, so TBOOT will be able to verify if certificate is
> valid. Storing another hash in VLP is not a problem. What do you think
> about that? Hardcoding certificate in TBOOT should be avoided at all
> costs.
> 
> Thanks,
> Lukasz
> 
> On Fri, 2019-09-27 at 15:35 +0000, Paul Moore (pmoore2) wrote:
> > Hi Lukasz,
> > 
> > Thanks for taking a look, I know it is a lot to ask.  When looking
> > at
> > the patches I'm mostly concerned about feedback on the general
> > concepts
> > at this stage; the patches are still very much a work in
> > progress.  My
> > goal in posting this on-list was to get some feedback now to see if
> > this
> > is something that would be of interest to the project.  I would hate
> > to
> > spend a few more months on this only to find out that tboot has not
> > interest in signature verification :)
> > 
> > As far as changes to the VLP are concerned, if you look at the patch
> > titled "tboot: add PECOFF signature verification hooks" you will see
> > that two of the TODO items are ...
> > 
> > - Support for kernel signature verification in the tboot policy.
> >   This probably means specifying a signing certificate as part of
> >   the policy.  We want to support certificate chains.  Backwards
> >   compatibility is a must.
> > - If the tboot policy can not be easily extended to support
> >   signature verification, we could consider embedding the
> >   certificate into the tboot binary at build time, similar to what
> >   is done with the UEFI Secure Boot shim.
> > 
> > I would obviously prefer to add a signing certificate or CA to the
> > VLP,
> > but I haven't done enough investigation into the VLP format to know
> > if
> > that is practical.  As a fallback I could envision embedding the
> > certificate into the binary (as the current prototype does), but
> > that
> > is
> > something I would like to avoid if possible.
> > 
> > As far as attestation and PCR values are concerned, my current
> > thought
> > is to hash the signing certificate into one PCR (say PCR A)
> > (assuming
> > the kernel signature is valid) and a combined hash of the
> > kernel/initrd/cmdline into a different PCR (say PCR B).  My thinking
> > is
> > that this would allow admins to seal/attest to either a specific
> > kernel/initrd/cmdline using PCR B or to the signing authority which
> > has
> > validated the kernel/etc. using PCR A.  However, I am open to other
> > ideas if you have suggestions - this effort is still in the early
> > stages.  This is one of the reasons I wanted to bring this effort to
> > the
> > list as soon as the basic idea (PECOFF signature verification in
> > tboot)
> > was working.
> > 
> > Thanks again,
> > -Paul
> > 
> > On Fri, 2019-09-27 at 13:43 +0200, Lukasz Hawrylko wrote:
> > > Hi Paul
> > > 
> > > Thank you for sharing your work. I will look at this patch and
> > > check
> > > how
> > > it works, idea of measuring kernel signature instead of whole
> > > binary
> > > is
> > > very interesting. I hope that next week I will find some time for
> > > that,
> > > as you said patch is quite big.
> > > 
> > > Do you plan to add ability to verify public key using VLP? If I
> > > understand correctly your current goal is to verify kernel binary
> > > with
> > > signature and extend PCRs with signature's public key hash, am I
> > > right?
> > > In this approach tboot is not able to verify if kernel is signed
> > > by
> > > proper authority, this need to be done be local/remote attestation
> > > in
> > > further boot process.
> > > 
> > > Thanks,
> > > Lukasz
> > > 
> > > 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 and now that I have a rough working prototype I wanted to
> > > > bring
> > > > it to the list to see if this is something the tboot community
> > > > would
> > > > be interested in eventually merging (once the work is more
> > > > complete
> > > > and polished).
> > > > 
> > > > The patchset is quite large, mostly due to the inclusion of
> > > > libtomcrypt and libtomfastmath to the tboot repository, so I'm
> > > > going
> > > > to refrain from spamming the list with the full patchset at this
> > > > early
> > > > stage.  The current patchset can be found on GitHub at the URL
> > > > below
> > > > (look in the "working-txtsig" branch):
> > > > 
> > > > * 
> > > > https://github.com/pcmoore/misc-tboot/tree/working-txtsig
> > > > 
> > > > 
> > > > 
> > > > The prototype doesn't actually enforce any policy or change the
> > > > PCR
> > > > measurements based on the kernel signatures (both are planned
> > > > work
> > > > items), but it does demonstrate the ability to parse and verify
> > > > a
> > > > signed PECOFF image.  The individual patch descriptions provide
> > > > some
> > > > additional information on some of the planned work to take this
> > > > from
> > > > a prototype to a proper implementation.
> > > > 
> > > > My motivation for this work is to create a mechanism that is
> > > > capable
> > > > of generating a stable set of PCR values across multiple kernels
> > > > that
> > > > can be used to seal TPM NVRAM secrets on both legacy BIOS and
> > > > UEFI
> > > > systems.  Imagine being able to store a storage encryption key
> > > > in
> > > > the
> > > > TPM, and restricting access to that key to only authorized
> > > > kernels
> > > > in
> > > > such a way that didn't require changing the tboot policy when
> > > > booting
> > > > different kernels.  I imagine I'm not along in thinking this
> > > > would
> > > > be a nice capability to have, especially on systems that don't
> > > > support
> > > > UEFI Secure Boot.
> > > > 
> > > > For those who are interested, I gave a presentation on this work
> > > > at
> > > > the Linux Security Summit last month, the video and sldies are
> > > > available at the links below:
> > > > 
> > > > * 
> > > > https://www.youtube.com/watch?v=Qbjz_5jUE9o
> > > > 
> > > > 
> > > > * 
> > > > https://www.paul-moore.com/docs/lss-securing_tpm_with_txt-pmoore-201909-r2.pdf
> > > > 
> > > > 
> > > > 
> > > > Thoughts?  Is this capability something the TXT/tboot community
> > > > would
> > > > be interested in merging into the main tboot repository once it
> > > > is
> > > > more complete?
> > > > 
> > > > _______________________________________________
> > > > tboot-devel mailing list
> > > > tbo...@li...
> > > > 
> > > > 
> > > > https://lists.sourceforge.net/lists/listinfo/tboot-devel
> > > > 
> > > > 
> > > > 

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

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

Hi Paul

We are going to have internal discussion about this feature in two
weeks, I have to prepare some presentation, so be prepare for questions
in near future :)

I have built version with your patch, looks like verification is working
with Fedora's kernel indeed. However I was not be able to verify kernel
signed with my testing certificate, did you try that? TBOOT is hanging
on:

    TBOOT: >>> DBG/SIG: mod[0], pkcs7 parsing

I guess that pkcs7_signeddata_parse can't read kernel signature, if you
want to test it by yourself here are commands that I was using:

    openssl req -newkey rsa:4096 -nodes -keyout db.key -new -x509 \
        -sha256 -days 3650 -subj "/CN=my Signature Database key/" \
        -out db.crt
    openssl x509 -outform DER -in db.crt -out db.cer
    sbsign --key db.key --cert db.crt --output bzImage_signed bzImage

Adding certificate to VLP has one major disadvantage - VLP is stored in
TPM NV that has very limited space. Putting ~1kB certificate there is in
my opinion bad idea. I would suggest to implement the same mechanism as
we already have for LCP. Certificate will be stored on disk and will be
passed to TBOOT using multiboot2 protocol. In VLP there will be only
hash of that file, so TBOOT will be able to verify if certificate is
valid. Storing another hash in VLP is not a problem. What do you think
about that? Hardcoding certificate in TBOOT should be avoided at all
costs.

Thanks,
Lukasz

On Fri, 2019-09-27 at 15:35 +0000, Paul Moore (pmoore2) wrote:
> Hi Lukasz,
> 
> Thanks for taking a look, I know it is a lot to ask.  When looking at
> the patches I'm mostly concerned about feedback on the general
> concepts
> at this stage; the patches are still very much a work in progress.  My
> goal in posting this on-list was to get some feedback now to see if
> this
> is something that would be of interest to the project.  I would hate
> to
> spend a few more months on this only to find out that tboot has not
> interest in signature verification :)
> 
> As far as changes to the VLP are concerned, if you look at the patch
> titled "tboot: add PECOFF signature verification hooks" you will see
> that two of the TODO items are ...
> 
> - Support for kernel signature verification in the tboot policy.
>   This probably means specifying a signing certificate as part of
>   the policy.  We want to support certificate chains.  Backwards
>   compatibility is a must.
> - If the tboot policy can not be easily extended to support
>   signature verification, we could consider embedding the
>   certificate into the tboot binary at build time, similar to what
>   is done with the UEFI Secure Boot shim.
> 
> I would obviously prefer to add a signing certificate or CA to the
> VLP,
> but I haven't done enough investigation into the VLP format to know if
> that is practical.  As a fallback I could envision embedding the
> certificate into the binary (as the current prototype does), but that
> is
> something I would like to avoid if possible.
> 
> As far as attestation and PCR values are concerned, my current thought
> is to hash the signing certificate into one PCR (say PCR A) (assuming
> the kernel signature is valid) and a combined hash of the
> kernel/initrd/cmdline into a different PCR (say PCR B).  My thinking
> is
> that this would allow admins to seal/attest to either a specific
> kernel/initrd/cmdline using PCR B or to the signing authority which
> has
> validated the kernel/etc. using PCR A.  However, I am open to other
> ideas if you have suggestions - this effort is still in the early
> stages.  This is one of the reasons I wanted to bring this effort to
> the
> list as soon as the basic idea (PECOFF signature verification in
> tboot)
> was working.
> 
> Thanks again,
> -Paul
> 
> On Fri, 2019-09-27 at 13:43 +0200, Lukasz Hawrylko wrote:
> > Hi Paul
> > 
> > Thank you for sharing your work. I will look at this patch and check
> > how
> > it works, idea of measuring kernel signature instead of whole binary
> > is
> > very interesting. I hope that next week I will find some time for
> > that,
> > as you said patch is quite big.
> > 
> > Do you plan to add ability to verify public key using VLP? If I
> > understand correctly your current goal is to verify kernel binary
> > with
> > signature and extend PCRs with signature's public key hash, am I
> > right?
> > In this approach tboot is not able to verify if kernel is signed by
> > proper authority, this need to be done be local/remote attestation
> > in
> > further boot process.
> > 
> > Thanks,
> > Lukasz
> > 
> > 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 and now that I have a rough working prototype I wanted to
> > > bring
> > > it to the list to see if this is something the tboot community
> > > would
> > > be interested in eventually merging (once the work is more
> > > complete
> > > and polished).
> > > 
> > > The patchset is quite large, mostly due to the inclusion of
> > > libtomcrypt and libtomfastmath to the tboot repository, so I'm
> > > going
> > > to refrain from spamming the list with the full patchset at this
> > > early
> > > stage.  The current patchset can be found on GitHub at the URL
> > > below
> > > (look in the "working-txtsig" branch):
> > > 
> > > * 
> > > https://github.com/pcmoore/misc-tboot/tree/working-txtsig
> > > 
> > > 
> > > 
> > > The prototype doesn't actually enforce any policy or change the
> > > PCR
> > > measurements based on the kernel signatures (both are planned work
> > > items), but it does demonstrate the ability to parse and verify a
> > > signed PECOFF image.  The individual patch descriptions provide
> > > some
> > > additional information on some of the planned work to take this
> > > from
> > > a prototype to a proper implementation.
> > > 
> > > My motivation for this work is to create a mechanism that is
> > > capable
> > > of generating a stable set of PCR values across multiple kernels
> > > that
> > > can be used to seal TPM NVRAM secrets on both legacy BIOS and UEFI
> > > systems.  Imagine being able to store a storage encryption key in
> > > the
> > > TPM, and restricting access to that key to only authorized kernels
> > > in
> > > such a way that didn't require changing the tboot policy when
> > > booting
> > > different kernels.  I imagine I'm not along in thinking this would
> > > be a nice capability to have, especially on systems that don't
> > > support
> > > UEFI Secure Boot.
> > > 
> > > For those who are interested, I gave a presentation on this work
> > > at
> > > the Linux Security Summit last month, the video and sldies are
> > > available at the links below:
> > > 
> > > * 
> > > https://www.youtube.com/watch?v=Qbjz_5jUE9o
> > > 
> > > 
> > > * 
> > > https://www.paul-moore.com/docs/lss-securing_tpm_with_txt-pmoore-201909-r2.pdf
> > > 
> > > 
> > > 
> > > Thoughts?  Is this capability something the TXT/tboot community
> > > would
> > > be interested in merging into the main tboot repository once it is
> > > more complete?
> > > 
> > > _______________________________________________
> > > tboot-devel mailing list
> > > tbo...@li...
> > > 
> > > 
> > > https://lists.sourceforge.net/lists/listinfo/tboot-devel
> > > 
> > > 
> > > 

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

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

Hi Lukasz,

Thanks for taking a look, I know it is a lot to ask.  When looking at
the patches I'm mostly concerned about feedback on the general concepts
at this stage; the patches are still very much a work in progress.  My
goal in posting this on-list was to get some feedback now to see if this
is something that would be of interest to the project.  I would hate to
spend a few more months on this only to find out that tboot has not
interest in signature verification :)

As far as changes to the VLP are concerned, if you look at the patch
titled "tboot: add PECOFF signature verification hooks" you will see
that two of the TODO items are ...

- Support for kernel signature verification in the tboot policy.
  This probably means specifying a signing certificate as part of
  the policy.  We want to support certificate chains.  Backwards
  compatibility is a must.
- If the tboot policy can not be easily extended to support
  signature verification, we could consider embedding the
  certificate into the tboot binary at build time, similar to what
  is done with the UEFI Secure Boot shim.

I would obviously prefer to add a signing certificate or CA to the VLP,
but I haven't done enough investigation into the VLP format to know if
that is practical.  As a fallback I could envision embedding the
certificate into the binary (as the current prototype does), but that is
something I would like to avoid if possible.

As far as attestation and PCR values are concerned, my current thought
is to hash the signing certificate into one PCR (say PCR A) (assuming
the kernel signature is valid) and a combined hash of the
kernel/initrd/cmdline into a different PCR (say PCR B).  My thinking is
that this would allow admins to seal/attest to either a specific
kernel/initrd/cmdline using PCR B or to the signing authority which has
validated the kernel/etc. using PCR A.  However, I am open to other
ideas if you have suggestions - this effort is still in the early
stages.  This is one of the reasons I wanted to bring this effort to the
list as soon as the basic idea (PECOFF signature verification in tboot)
was working.

Thanks again,
-Paul

On Fri, 2019-09-27 at 13:43 +0200, Lukasz Hawrylko wrote:
> Hi Paul
> 
> Thank you for sharing your work. I will look at this patch and check
> how
> it works, idea of measuring kernel signature instead of whole binary
> is
> very interesting. I hope that next week I will find some time for
> that,
> as you said patch is quite big.
> 
> Do you plan to add ability to verify public key using VLP? If I
> understand correctly your current goal is to verify kernel binary with
> signature and extend PCRs with signature's public key hash, am I
> right?
> In this approach tboot is not able to verify if kernel is signed by
> proper authority, this need to be done be local/remote attestation in
> further boot process.
> 
> Thanks,
> Lukasz
> 
> 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 and now that I have a rough working prototype I wanted to
> > bring
> > it to the list to see if this is something the tboot community would
> > be interested in eventually merging (once the work is more complete
> > and polished).
> > 
> > The patchset is quite large, mostly due to the inclusion of
> > libtomcrypt and libtomfastmath to the tboot repository, so I'm going
> > to refrain from spamming the list with the full patchset at this
> > early
> > stage.  The current patchset can be found on GitHub at the URL below
> > (look in the "working-txtsig" branch):
> > 
> > * 
> > https://github.com/pcmoore/misc-tboot/tree/working-txtsig
> > 
> > 
> > The prototype doesn't actually enforce any policy or change the PCR
> > measurements based on the kernel signatures (both are planned work
> > items), but it does demonstrate the ability to parse and verify a
> > signed PECOFF image.  The individual patch descriptions provide some
> > additional information on some of the planned work to take this from
> > a prototype to a proper implementation.
> > 
> > My motivation for this work is to create a mechanism that is capable
> > of generating a stable set of PCR values across multiple kernels
> > that
> > can be used to seal TPM NVRAM secrets on both legacy BIOS and UEFI
> > systems.  Imagine being able to store a storage encryption key in
> > the
> > TPM, and restricting access to that key to only authorized kernels
> > in
> > such a way that didn't require changing the tboot policy when
> > booting
> > different kernels.  I imagine I'm not along in thinking this would
> > be a nice capability to have, especially on systems that don't
> > support
> > UEFI Secure Boot.
> > 
> > For those who are interested, I gave a presentation on this work at
> > the Linux Security Summit last month, the video and sldies are
> > available at the links below:
> > 
> > * 
> > https://www.youtube.com/watch?v=Qbjz_5jUE9o
> > 
> > * 
> > https://www.paul-moore.com/docs/lss-securing_tpm_with_txt-pmoore-201909-r2.pdf
> > 
> > 
> > Thoughts?  Is this capability something the TXT/tboot community
> > would
> > be interested in merging into the main tboot repository once it is
> > more complete?
> > 
> > _______________________________________________
> > tboot-devel mailing list
> > tbo...@li...
> > 
> > https://lists.sourceforge.net/lists/listinfo/tboot-devel
> > 
> > 

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

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

Hi Paul

Thank you for sharing your work. I will look at this patch and check how
it works, idea of measuring kernel signature instead of whole binary is
very interesting. I hope that next week I will find some time for that,
as you said patch is quite big.

Do you plan to add ability to verify public key using VLP? If I
understand correctly your current goal is to verify kernel binary with
signature and extend PCRs with signature's public key hash, am I right?
In this approach tboot is not able to verify if kernel is signed by
proper authority, this need to be done be local/remote attestation in
further boot process.

Thanks,
Lukasz

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 and now that I have a rough working prototype I wanted to bring
> it to the list to see if this is something the tboot community would
> be interested in eventually merging (once the work is more complete
> and polished).
> 
> The patchset is quite large, mostly due to the inclusion of
> libtomcrypt and libtomfastmath to the tboot repository, so I'm going
> to refrain from spamming the list with the full patchset at this early
> stage.  The current patchset can be found on GitHub at the URL below
> (look in the "working-txtsig" branch):
> 
> * 
> https://github.com/pcmoore/misc-tboot/tree/working-txtsig
> 
> 
> The prototype doesn't actually enforce any policy or change the PCR
> measurements based on the kernel signatures (both are planned work
> items), but it does demonstrate the ability to parse and verify a
> signed PECOFF image.  The individual patch descriptions provide some
> additional information on some of the planned work to take this from
> a prototype to a proper implementation.
> 
> My motivation for this work is to create a mechanism that is capable
> of generating a stable set of PCR values across multiple kernels that
> can be used to seal TPM NVRAM secrets on both legacy BIOS and UEFI
> systems.  Imagine being able to store a storage encryption key in the
> TPM, and restricting access to that key to only authorized kernels in
> such a way that didn't require changing the tboot policy when booting
> different kernels.  I imagine I'm not along in thinking this would
> be a nice capability to have, especially on systems that don't support
> UEFI Secure Boot.
> 
> For those who are interested, I gave a presentation on this work at
> the Linux Security Summit last month, the video and sldies are
> available at the links below:
> 
> * 
> https://www.youtube.com/watch?v=Qbjz_5jUE9o
> 
> * 
> https://www.paul-moore.com/docs/lss-securing_tpm_with_txt-pmoore-201909-r2.pdf
> 
> 
> Thoughts?  Is this capability something the TXT/tboot community would
> be interested in merging into the main tboot repository once it is
> more complete?
> 
> _______________________________________________
> tboot-devel mailing list
> tbo...@li...
> 
> https://lists.sourceforge.net/lists/listinfo/tboot-devel
> 
> 

Re: [tboot-devel] [ANNOUNCE] Boot Security microconf at Linux Plumbers Conf, Sep 9-11

[Rich P. <pe...@gm...>]

Notes from the LPC session are available:
https://etherpad.net/p/LPC2019_System_Boot_and_Security/export/html

There will be DRTM-related talks at PSEC 2019, Oct 1-3 in Redmond:
https://platformsecuritysummit.com

Rich

> On Jul 22, 2019, at 10:48, Rich Persaud <pe...@gm...> wrote:
> 
> https://www.linuxplumbersconf.org/blog/2019/system-boot-and-security-microconference-accepted-into-2019-linux-plumbers-conference/
> 
> System Boot and Security Microconference has been accepted into the 2019 Linux Plumbers Conference! Computer-system security is a topic that has gotten a lot of serious attention over the years, but there has not been anywhere near as much attention paid to the system firmware. But the firmware is also a target for those looking to wreak havoc on our systems. Firmware is now being developed with security in mind, but provides incomplete solutions. This microconference will focus on the security of the system especially from the time the system is powered on.
> 
> Expected topics for this year include:
> 
> TPMs
> SRTM and DRTM
> Intel TXT
> AMD SKINIT
> Attestation
> UEFI Secure Boot
> IMA
> Intel SGX
> Boot loaders
> Firmware
> OpenBMC
> 

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

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

Hello,

I've been working on adding PECOFF/kernel signature verification to
tboot and now that I have a rough working prototype I wanted to bring
it to the list to see if this is something the tboot community would
be interested in eventually merging (once the work is more complete
and polished).

The patchset is quite large, mostly due to the inclusion of
libtomcrypt and libtomfastmath to the tboot repository, so I'm going
to refrain from spamming the list with the full patchset at this early
stage.  The current patchset can be found on GitHub at the URL below
(look in the "working-txtsig" branch):

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

The prototype doesn't actually enforce any policy or change the PCR
measurements based on the kernel signatures (both are planned work
items), but it does demonstrate the ability to parse and verify a
signed PECOFF image.  The individual patch descriptions provide some
additional information on some of the planned work to take this from
a prototype to a proper implementation.

My motivation for this work is to create a mechanism that is capable
of generating a stable set of PCR values across multiple kernels that
can be used to seal TPM NVRAM secrets on both legacy BIOS and UEFI
systems.  Imagine being able to store a storage encryption key in the
TPM, and restricting access to that key to only authorized kernels in
such a way that didn't require changing the tboot policy when booting
different kernels.  I imagine I'm not along in thinking this would
be a nice capability to have, especially on systems that don't support
UEFI Secure Boot.

For those who are interested, I gave a presentation on this work at
the Linux Security Summit last month, the video and sldies are
available at the links below:

* https://www.youtube.com/watch?v=Qbjz_5jUE9o
* 
https://www.paul-moore.com/docs/lss-securing_tpm_with_txt-pmoore-201909-r2.pdf

Thoughts?  Is this capability something the TXT/tboot community would
be interested in merging into the main tboot repository once it is
more complete?

Re: [tboot-devel] EXTERNAL: Re: GETSEC[SENTER]....and then reset

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

On Tue, Sep 10, 2019 at 01:41:53AM +0000, Haskins, Robert wrote:

Hi Robert, I hope your day is going well.

My apologies for the delay in responding.  Lots of fires to put out
and I needed to go back and look at some notes.

> OK, here is my latest TBOOT log. It looks like we did get an error
> code (TXT.ERRORCODE: 0xc0007051) this time around:

The parse_err utility that comes with the tboot package is your
friend.  If you run that numeric error code through it you get the
following:

AC module error : acm_type=0x1, progress=0x05, error=0x1c

tboot is decoding the error as well, ie:

> TBOOT: TXT.ERRORCODE: 0xc0007051
> TBOOT: AC module error : acm_type=0x1, progress=0x05, error=0x1c

If you downloaded the .zip file containing the ACM module it should
have a spreadsheet that details the various internal errors.  It
doesn't match well with the 'progress' or 'error' fields but the 0x1c
code gives some idea on where to start looking.

The most likely candidate error is the following:

---------------------------------------------------------------------------
ERR_INVALID_INPUT_PARA

Internal error. TPM driver detected invalid function input
parameter.
---------------------------------------------------------------------------

Which, given the following output in your logfile:

> TBOOT: reading Verified Launch Policy from TPM NV...
> TBOOT: TPM: fail to get public data of 0x01200001 in TPM NV
> TBOOT: 	:reading failed
> TBOOT: reading Launch Control Policy from TPM NV...
> TBOOT: TPM: fail to get public data of 0x01400001 in TPM NV
> TBOOT: 	:reading failed
> TBOOT: failed to read policy from TPM NV, using default

Probably suggests that the ACM is unhappy about the fact that, at a
minimum, the Platform Owner (PO) NVRAM index has not been configured.

The Intel TXT Software Development Manual (SDM) indicates that the
Platform Supplier (PS), PO and Auxiliary (AUX) NVRAM index locations
are required to be configured.  If you grab a copy of the SDM this
information should be on page 155 or thereabouts

Hopefully, whoever is vending your platform, has TXT 'provisioned' the
platform which involves, at a minimum, configuring the PS NVRAM index.
It has been our experience that you need the Intel supplied TXT/TPM
provisioning tools in order to do this and those are, at our last
experience, only available under NDA.

All of the Intel vended platforms that we have dealt with have been
TXT provisioned.  We had a tough go round with Gigabyte boards which
appeared to have been either not provisioned or provisioned
incorrectly and were thus unusable for TXT.  So caveat emptor for
anyone who stumbles across this message on the INTERNET.

The relevant TPM2 NVRAM indexes are as follows:

PS:  0x1800001 or 0x1c10103
PO:  0x1400001 or 0x1c10106
AUX: 0x1800003 or 0x1c10102
SGX: 0x1800004 or 0x1c10104

The NVRAM index range that is to be used is dependent on the ACM
module.  The tboot package has the acminfo command, if you run that on
your module you will see the following in the output:

TPM capability:
	ext_policy: 0x3
	tpm_family : 0x3
	tpm_nv_index_set : 0x0

The tpm_nv_index_set variable indicates the NVRAM index range that the
ACM is intending to use.  You can also see this in the following
section of your log:

> TBOOT: 	 TPM info list:
> TBOOT: 		 TPM capability:
> TBOOT: 		      ext_policy: 0x3
> TBOOT: 		      tpm_family : 0x3
> TBOOT: 		      tpm_nv_index_set : 0x0

tpm_nv_index_set 0 means the ACM is using the 0x18xxxxx and 0x14xxxxx
locations.

In your previous mail you referred to the following:

> 3) I am not sure what you mean by this question. Are you referring to index
> 0x1c10103? (see https://sourceforge.net/p/tboot/mailman/message/35551544/)

The message you are referring to with the URL is a bit of a red
herring in all of this, since Travis Gilbert works/worked for Dell and
was working on a platform that had the ACM module included with the
platform BIOS/firwmare.  I suspect they were doing early ground work
in preparation for delivering systems which support the Windows
'System Guard' feature, which is an implementation of Dynamic Root of
Trust for Measurement (DRTM) for the Windows platform.

The downloable 7th/8th gen ACM modules are using index set 1 locations
but that is the first downloadable ACM to move to the higher order
NVRAM indexes.  I suspect that is the first generation of hardware
that is actively supporting System Guard.

So you will need to make sure that the PS, PO and AUX indexes are
created and with the proper attributes.

Table J-2 in Appendix J of the TXT/SDM has details on how to properly
configure the NVRAM index locations.  Here is a summary table that may
be useful for your efforts:

---------------------------------------------------------------------------
PS index:
	PS1 attributes (non-permanent): 0x42040408
		TPMA_NV_POLICYWRITE
		TPMA_NV_POLICY_DELETE
		TPMA_NV_AUTHREAD
		TPMA_NV_NO_DA
		TPMA_NV_PLATFORMCREATE
	Size:	38 + HASHALGID_DIGEST_SIZE
		SHA256: 70

AUX index:
	Attributes: 0x42044408
		TPMA_NV_POLICYWRITE
		TPMA_NV_POLICY_DELETE
		TPMA_NV_WRITE_STCLEAR
		TPMA_NV_AUTHREAD
		TPMA_NV_NO_DA
		TPMA_NV_PLATFORMCREATE
	Size: 40 + 2 * HASHALGID_DIGEST_SIZE
		SHA256: 104

SGX index:
	Attributes: 0x42040404
		TPMA_NV_AUTHWRITE
		TPMA_NV_POLICY_DELETE
		TPMA_NV_AUTHREAD
		TPMA_NV_NO_DA
		TPMA_NV_PLATFORMCREATE
	Size:
		all: 8

PO index:
	Attributes Broadwell: 0x4000A
		TPMA_NV_OWNERWRITE
		TPMA_NV_POLICYWRITE
		TPMA_NV_AUTHREAD
	Attributes post-Skylake: 0x204000A
		TPMA_NV_OWNERWRITE
		TPMA_NV_POLICYWRITE
		TPMA_NV_AUTHREAD
		TPMA_NV_NO_DA
	Size:	38 + HASHALGID_DIGEST_SIZE
		SHA256: 70
---------------------------------------------------------------------------

I see from your logs that you are allowing tboot to default to using
SHA1 for its measurement algorithm.  Since you are getting started
with all of this I would recommand you use the following command line
arguement for tboot:

extpol=sha256

That will configure tboot to use SHA256 for its measurement and
hashing.  The size attributes for the NVRAM index locations in the
above NVRAM summary are based on SHA256.

So your next step will be to find a set of TPM2 command-line utilities
that you are comfortable with and work on getting the PO and AUX NVRAM
index locations created with the proper size and attributes and to
verify that the PS index has been configured.

I'm assuming that Lockheed Martin has enough juice with Intel to get
the necessary tooling if your platform has not been TXT provisioned.
Either that or enough juice with your hardware OEM in order to get
them to vend properly provisioned platforms in order make this
technology useful in support of your security initiatives.

We built a TPM2 toolbox on top of Ken Goldman's TSS2 library, the
latter of which is simply excellent.  Ken is at IBM TJ Watson, and I
believe, sits on the TCG/TPM2 steering committee for IBM and probably
knows as much about TPM's as anyone on the planet.

The 0x1200001 NVRAM location is for a Verified Launch Policy (VLP)
measurement, that is an invention of tboot's.  It is not strictly
necessary from the perspective of getting the ACM to a point where it
will not simply reset the platform.

I see from your logs that you have an SGX capable platform:

> TBOOT: SGX:verify_IA32_se_svn_status is called
> TBOOT: SGX is enabled, cpuid.ebx:0x29c6fbf
> TBOOT: Comparing se_svn with ACM Header se_svn
> TBOOT: se_svn is equal to ACM se_svn

You may want to keep in the back of your mind that the ACM may also be
unhappy if it doesn't have the SGX NVRAM index provisioned as well.

So if you move forward with these configurations it should advance you
to the point where the platform will act a bit more hospitably.

The target for your efforts should be to get a successful system boot
with a LCP_ANY policy written into the 0x1400001 index location using
SHA256 as the measurement algorithm.  Once you are at that point you
will at least have verified there are no 'gotchas' in the hardware and
you can begin advancing to more sophisticated launch control policies.

Hopefully all of this is useful information in pursuit of advancing
the Lockheed/Martin security efforts.... :-)

Speaking of which I was doing a presentation on the application of SGX
security technology to the implementation of autonomously
self-defensive computing platforms at the National Defense Industry
Association (NDIA) cyber-security conference in Austin, TX in March.
A Lockheed engineer that was attending ended up engaging me a couple
of times regarding our work.

We develop something that we call the Secure Runtime Development
Environment (SRDE) that integrates all of these technologies in order
to allow the rapid creation of purpose built platforms that are
capable of independently defending themselves.

BTW: Yes, we have done a lot of work on TXT and SGX.  Unfortunately,
at a time when it is absolutely critical that we advance our
industrial cyber-security posture, the barriers to effectively using
hardware platform security are nothing short of horrendous... :-)(

Let us know how things go with your efforts.

Good luck with your project.

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...
------------------------------------------------------------------------------
"Politics is the business of getting power and privilege without possessing
 merit."
                                -- P.J. O'Rourke

Re: [tboot-devel] EXTERNAL: Re: GETSEC[SENTER]....and then reset

[Haskins, R. <rob...@lm...>]

OK, here is my latest TBOOT log. It looks like we did get an error code
(TXT.ERRORCODE: 0xc0007051) this time around:

TBOOT: IA32_FEATURE_CONTROL_MSR: 0000ff07
TBOOT: CPU is SMX-capable
TBOOT: SMX is enabled
TBOOT: TXT chipset and all needed capabilities present
TBOOT: *********************** TBOOT ***********************
TBOOT:    2019-04-10 11:00 +0200 1.9.10
TBOOT: *****************************************************
TBOOT: command line: logging=serial,memory
TBOOT: IA32_FEATURE_CONTROL_MSR: 0000ff07
TBOOT: CPU is SMX-capable
TBOOT: CPU is VMX-capable
TBOOT: SMX is enabled
TBOOT: TXT chipset and all needed capabilities present
TBOOT: IA32_FEATURE_CONTROL_MSR: 0000ff07
TBOOT: CPU is SMX-capable
TBOOT: CPU is VMX-capable
TBOOT: SMX is enabled
TBOOT: TXT chipset and all needed capabilities present
TBOOT: BSP is cpu 0
TBOOT: original e820 map:
TBOOT: 	0000000000000000 - 0000000000058000  (1)
TBOOT: 	0000000000058000 - 0000000000059000  (2)
TBOOT: 	0000000000059000 - 000000000009e000  (1)
TBOOT: 	000000000009e000 - 0000000000100000  (2)
TBOOT: 	0000000000100000 - 000000005d4e1000  (1)
TBOOT: 	000000005d4e1000 - 000000005d4e2000  (4)
TBOOT: 	000000005d4e2000 - 000000005d4e3000  (2)
TBOOT: 	000000005d4e3000 - 000000005ef88000  (1)
TBOOT: 	000000005ef88000 - 000000005f888000  (2)
TBOOT: 	000000005f888000 - 0000000075a9f000  (1)
TBOOT: 	0000000075a9f000 - 0000000075c9f000  (20)
TBOOT: 	0000000075c9f000 - 000000007648f000  (2)
TBOOT: 	000000007648f000 - 0000000076b7f000  (4)
TBOOT: 	0000000076b7f000 - 0000000076bff000  (3)
TBOOT: 	0000000076bff000 - 0000000076c00000  (1)
TBOOT: 	0000000076c00000 - 0000000080000000  (2)
TBOOT: 	00000000e0000000 - 00000000f0000000  (2)
TBOOT: 	00000000fd000000 - 00000000fe800000  (2)
TBOOT: 	00000000fec00000 - 00000000fec01000  (2)
TBOOT: 	00000000fed00000 - 00000000fed01000  (2)
TBOOT: 	00000000fed10000 - 00000000fed1a000  (2)
TBOOT: 	00000000fed20000 - 00000000fed80000  (2)
TBOOT: 	00000000fed84000 - 00000000fed85000  (2)
TBOOT: 	00000000fee00000 - 00000000fee01000  (2)
TBOOT: 	00000000ff900000 - 0000000100000000  (2)
TBOOT: 	0000000100000000 - 000000047e000000  (1)
TBOOT: checking if module  is an SINIT for this platform...
TBOOT: chipset production fused: 1
TBOOT: chipset ids: vendor: 0x8086, device: 0xb006, revision: 0x1
TBOOT: processor family/model/stepping: 0x806ea
TBOOT: platform id: 0x1c000000000000
TBOOT: 	 1 ACM chipset id entries:
TBOOT: 	     vendor: 0x8086, device: 0xc002, flags: 0x1, revision: 0x7,
extended: 0x0
TBOOT: 	 chipset id mismatch
TBOOT: checking if module  is an SINIT for this platform...
TBOOT: 	 1 ACM chipset id entries:
TBOOT: 	     vendor: 0x8086, device: 0xa000, flags: 0x1, revision: 0x1,
extended: 0x0
TBOOT: 	 chipset id mismatch
TBOOT: checking if module  is an SINIT for this platform...
TBOOT: 	 1 ACM chipset id entries:
TBOOT: 	     vendor: 0x8086, device: 0xc000, flags: 0x1, revision: 0x3f,
extended: 0x0
TBOOT: 	 chipset id mismatch
TBOOT: checking if module  is an SINIT for this platform...
TBOOT: 	 1 ACM chipset id entries:
TBOOT: 	     vendor: 0x8086, device: 0xc000, flags: 0x1, revision: 0x7,
extended: 0x0
TBOOT: 	 chipset id mismatch
TBOOT: checking if module  is an SINIT for this platform...
TBOOT: 	 1 ACM chipset id entries:
TBOOT: 	     vendor: 0x8086, device: 0x8003, flags: 0x1, revision: 0xf,
extended: 0x0
TBOOT: 	 chipset id mismatch
TBOOT: checking if module  is an SINIT for this platform...
TBOOT: 	 1 ACM chipset id entries:
TBOOT: 	     vendor: 0x8086, device: 0x8001, flags: 0x1, revision: 0x7,
extended: 0x0
TBOOT: 	 chipset id mismatch
TBOOT: checking if module  is an SINIT for this platform...
TBOOT: 	 1 ACM chipset id entries:
TBOOT: 	     vendor: 0x8086, device: 0x9000, flags: 0x1, revision: 0x3f,
extended: 0x0
TBOOT: 	 chipset id mismatch
TBOOT: checking if module  is an SINIT for this platform...
TBOOT: 	 ACM info_table version mismatch (6)
TBOOT: 	 1 ACM chipset id entries:
TBOOT: 	     vendor: 0x8086, device: 0xb008, flags: 0x1, revision: 0x1,
extended: 0x0
TBOOT: 	 chipset id mismatch
TBOOT: checking if module  is an SINIT for this platform...
TBOOT: 	 ACM info_table version mismatch (6)
TBOOT: 	 1 ACM chipset id entries:
TBOOT: 	     vendor: 0x8086, device: 0xb006, flags: 0x1, revision: 0x1,
extended: 0x0
TBOOT: 	 2 ACM processor id entries:
TBOOT: 	     fms: 0x406e0, fms_mask: 0xfff3ff0, platform_id: 0x0,
platform_mask: 0x0
TBOOT: 	     fms: 0x506e0, fms_mask: 0xfff3ff0, platform_id: 0x0,
platform_mask: 0x0
TBOOT: 	 processor mismatch
TBOOT: checking if module  is an SINIT for this platform...
TBOOT: 	 ACM info_table version mismatch (6)
TBOOT: 	 1 ACM chipset id entries:
TBOOT: 	     vendor: 0x8086, device: 0xb006, flags: 0x1, revision: 0x1,
extended: 0x0
TBOOT: 	 4 ACM processor id entries:
TBOOT: 	     fms: 0x406e0, fms_mask: 0xfff3ff0, platform_id: 0x0,
platform_mask: 0x0
TBOOT: 	     fms: 0x506e0, fms_mask: 0xfff3ff0, platform_id: 0x0,
platform_mask: 0x0
TBOOT: 	     fms: 0x806e0, fms_mask: 0xfff3ff0, platform_id: 0x0,
platform_mask: 0x0
TBOOT: SINIT matches platform
TBOOT: TXT.SINIT.BASE: 0x76ed0000
TBOOT: TXT.SINIT.SIZE: 0x50000 (327680)
TBOOT: copied SINIT (size=20000) to 0x76ed0000
TBOOT: AC mod base alignment OK
TBOOT: AC mod size OK
TBOOT: AC module header dump for SINIT:
TBOOT: 	 type: 0x2 (ACM_TYPE_CHIPSET)
TBOOT: 	 subtype: 0x0 
TBOOT: 	 length: 0xa1 (161)
TBOOT: 	 version: 0
TBOOT: 	 chipset_id: 0xb006
TBOOT: 	 flags: 0x0
TBOOT: 		 pre_production: 0
TBOOT: 		 debug_signed: 0
TBOOT: 	 vendor: 0x8086
TBOOT: 	 date: 0x20180904
TBOOT: 	 size*4: 0x20000 (131072)
TBOOT: 	 txt_svn: 0x00000000
TBOOT: 	 se_svn: 0x00000004
TBOOT: 	 code_control: 0x0
TBOOT: 	 entry point: 0x00000008:0000e418
TBOOT: 	 scratch_size: 0x8f (143)
TBOOT: 	 info_table:
TBOOT: 		 uuid: {0x7fc03aaa, 0x46a7, 0x18db, 0xac2e,
		{0x69, 0x8f, 0x8d, 0x41, 0x7f, 0x5a}}
TBOOT: 		     ACM_UUID_V3
TBOOT: 		 chipset_acm_type: 0x1 (SINIT)
TBOOT: 		 version: 6
TBOOT: 		 length: 0x30 (48)
TBOOT: 		 chipset_id_list: 0x4f0
TBOOT: 		 os_sinit_data_ver: 0x7
TBOOT: 		 min_mle_hdr_ver: 0x00020000
TBOOT: 		 capabilities: 0x0000036e
TBOOT: 		     rlp_wake_getsec: 0
TBOOT: 		     rlp_wake_monitor: 1
TBOOT: 		     ecx_pgtbl: 1
TBOOT: 		     stm: 1
TBOOT: 		     pcr_map_no_legacy: 0
TBOOT: 		     pcr_map_da: 1
TBOOT: 		     platform_type: 1
TBOOT: 		     max_phy_addr: 1
TBOOT: 		     tcg_event_log_format: 1
TBOOT: 		 acm_ver: 171
TBOOT: 	 chipset list:
TBOOT: 		 count: 1
TBOOT: 		 entry 0:
TBOOT: 		     flags: 0x1
TBOOT: 		     vendor_id: 0x8086
TBOOT: 		     device_id: 0xb006
TBOOT: 		     revision_id: 0x1
TBOOT: 		     extended_id: 0x0
TBOOT: 	 processor list:
TBOOT: 		 count: 4
TBOOT: 		 entry 0:
TBOOT: 		     fms: 0x406e0
TBOOT: 		     fms_mask: 0xfff3ff0
TBOOT: 		     platform_id: 0x0
TBOOT: 		     platform_mask: 0x0
TBOOT: 		 entry 1:
TBOOT: 		     fms: 0x506e0
TBOOT: 		     fms_mask: 0xfff3ff0
TBOOT: 		     platform_id: 0x0
TBOOT: 		     platform_mask: 0x0
TBOOT: 		 entry 2:
TBOOT: 		     fms: 0x806e0
TBOOT: 		     fms_mask: 0xfff3ff0
TBOOT: 		     platform_id: 0x0
TBOOT: 		     platform_mask: 0x0
TBOOT: 		 entry 3:
TBOOT: 		     fms: 0x906e0
TBOOT: 		     fms_mask: 0xfff3ff0
TBOOT: 		     platform_id: 0x0
TBOOT: 		     platform_mask: 0x0
TBOOT: 	 TPM info list:
TBOOT: 		 TPM capability:
TBOOT: 		      ext_policy: 0x3
TBOOT: 		      tpm_family : 0x3
TBOOT: 		      tpm_nv_index_set : 0x0
TBOOT: 		 alg count: 6
TBOOT: 		     alg_id: 0x4
TBOOT: 		     alg_id: 0xb
TBOOT: 		     alg_id: 0xc
TBOOT: 		     alg_id: 0xd
TBOOT: 		     alg_id: 0x14
TBOOT: 		     alg_id: 0x18
TBOOT: TPM: TPM 2.0 FIFO interface is active...
TBOOT: TPM: FIFO_INF Locality 0 is open
TBOOT: TPM: discrete TPM2.0 Family 0x1
TBOOT: TPM: supported bank count = 2
TBOOT: TPM: bank alg = 00000004
TBOOT: TPM: bank alg = 0000000b
TBOOT: tboot: supported alg count = 2
TBOOT: tboot: hash alg = 00000004
TBOOT: tboot: hash alg = 0000000B
TBOOT: TPM:CreatePrimary creating hierarchy handle = 40000007
TBOOT: TPM:CreatePrimary created object handle = 80000000
TBOOT: TPM attribute:
TBOOT: 	 extend policy: 2
TBOOT: 	 current alg id: 0x4
TBOOT: 	 timeout values: A: 750, B: 2000, C: 75000, D: 750
TBOOT: SGX:verify_IA32_se_svn_status is called
TBOOT: SGX is enabled, cpuid.ebx:0x29c6fbf
TBOOT: Comparing se_svn with ACM Header se_svn
TBOOT: se_svn is equal to ACM se_svn
TBOOT: reading Verified Launch Policy from TPM NV...
TBOOT: TPM: fail to get public data of 0x01200001 in TPM NV
TBOOT: 	:reading failed
TBOOT: reading Launch Control Policy from TPM NV...
TBOOT: TPM: fail to get public data of 0x01400001 in TPM NV
TBOOT: 	:reading failed
TBOOT: failed to read policy from TPM NV, using default
TBOOT: policy:
TBOOT: 	 version: 2
TBOOT: 	 policy_type: TB_POLTYPE_CONT_NON_FATAL
TBOOT: 	 hash_alg: TB_HALG_SHA1
TBOOT: 	 policy_control: 00000001 (EXTEND_PCR17)
TBOOT: 	 num_entries: 3
TBOOT: 	 policy entry[0]:
TBOOT: 		 mod_num: 0
TBOOT: 		 pcr: none
TBOOT: 		 hash_type: TB_HTYPE_ANY
TBOOT: 		 num_hashes: 0
TBOOT: 	 policy entry[1]:
TBOOT: 		 mod_num: any
TBOOT: 		 pcr: 19
TBOOT: 		 hash_type: TB_HTYPE_ANY
TBOOT: 		 num_hashes: 0
TBOOT: 	 policy entry[2]:
TBOOT: 		 mod_num: nv_raw
		 nv_index: 40000010
TBOOT: 		 pcr: 22
TBOOT: 		 hash_type: TB_HTYPE_ANY
TBOOT: 		 num_hashes: 0
TBOOT: no policy in TPM NV.
TBOOT: IA32_FEATURE_CONTROL_MSR: 0000ff07
TBOOT: CPU is SMX-capable
TBOOT: CPU is VMX-capable
TBOOT: SMX is enabled
TBOOT: TXT chipset and all needed capabilities present
TBOOT: TXT.ERRORCODE: 0xc0007051
TBOOT: AC module error : acm_type=0x1, progress=0x05, error=0x1c
TBOOT: TXT.ESTS: 0x0
TBOOT: TXT.E2STS: 0xc
TBOOT: IA32_FEATURE_CONTROL_MSR: 0000ff07
TBOOT: CPU is SMX-capable
TBOOT: CPU is VMX-capable
TBOOT: SMX is enabled
TBOOT: TXT chipset and all needed capabilities present
TBOOT: TXT.HEAP.BASE: 0x76f20000
TBOOT: TXT.HEAP.SIZE: 0xe0000 (917504)
TBOOT: unsupported BIOS data version (6)
TBOOT: bios_data (@0x76f20008, 0x56):
TBOOT: 	 version: 6
TBOOT: 	 bios_sinit_size: 0x0 (0)
TBOOT: 	 lcp_pd_base: 0x0
TBOOT: 	 lcp_pd_size: 0x0 (0)
TBOOT: 	 num_logical_procs: 8
TBOOT: 	 flags: 0x200000000
TBOOT: 	 ext_data_elts[]:
TBOOT: 		 BIOS_SPEC_VER:
TBOOT: 		     major: 0x2
TBOOT: 		     minor: 0x1
TBOOT: 		     rev: 0x0
TBOOT: 		 ACM:
TBOOT: 		     num_acms: 1
TBOOT: 		     acm_addrs[0]: 0xffe42000
TBOOT: IA32_FEATURE_CONTROL_MSR: 0000ff07
TBOOT: CPU is SMX-capable
TBOOT: CPU is VMX-capable
TBOOT: SMX is enabled
TBOOT: TXT chipset and all needed capabilities present
TBOOT: CR0 and EFLAGS OK
TBOOT: supports preserving machine check errors
TBOOT: CPU support processor-based S-CRTM
TBOOT: CPU is ready for SENTER
TBOOT: checking previous errors on the last boot.
	last boot has error.
TBOOT: TPM: TPM 2.0 FIFO interface is active...
TBOOT: file addresses:
TBOOT: 	 &_start=0x804000
TBOOT: 	 &_end=0xb57ca0
TBOOT: 	 &_mle_start=0x804000
TBOOT: 	 &_mle_end=0x83b000
TBOOT: 	 &_post_launch_entry=0x804010
TBOOT: 	 &_txt_wakeup=0x804200
TBOOT: 	 &g_mle_hdr=0x81e960
TBOOT: MLE header:
TBOOT: 	 uuid={0x9082ac5a, 0x476f, 0x74a7, 0x5c0f,
		{0x55, 0xa2, 0xcb, 0x51, 0xb6, 0x42}}
TBOOT: 	 length=34
TBOOT: 	 version=00020001
TBOOT: 	 entry_point=00000010
TBOOT: 	 first_valid_page=00000000
TBOOT: 	 mle_start_off=4000
TBOOT: 	 mle_end_off=3b000
TBOOT: 	 capabilities: 0x00000227
TBOOT: 	     rlp_wake_getsec: 1
TBOOT: 	     rlp_wake_monitor: 1
TBOOT: 	     ecx_pgtbl: 1
TBOOT: 	     stm: 0
TBOOT: 	     pcr_map_no_legacy: 0
TBOOT: 	     pcr_map_da: 1
TBOOT: 	     platform_type: 0
TBOOT: 	     max_phy_addr: 0
TBOOT: 	     tcg_event_log_format: 1
TBOOT: MLE start=0x804000, end=0x83b000, size=0x37000
TBOOT: ptab_size=3000, ptab_base=0x801000
TBOOT: TXT.HEAP.BASE: 0x76f20000
TBOOT: TXT.HEAP.SIZE: 0xe0000 (917504)
TBOOT: unsupported BIOS data version (6)
TBOOT: bios_data (@0x76f20008, 0x56):
TBOOT: 	 version: 6
TBOOT: 	 bios_sinit_size: 0x0 (0)
TBOOT: 	 lcp_pd_base: 0x0
TBOOT: 	 lcp_pd_size: 0x0 (0)
TBOOT: 	 num_logical_procs: 8
TBOOT: 	 flags: 0x200000000
TBOOT: 	 ext_data_elts[]:
TBOOT: 		 BIOS_SPEC_VER:
TBOOT: 		     major: 0x2
TBOOT: 		     minor: 0x1
TBOOT: 		     rev: 0x0
TBOOT: 		 ACM:
TBOOT: 		     num_acms: 1
TBOOT: 		     acm_addrs[0]: 0xffe42000
TBOOT: discarding RAM above reserved regions: 0x5d4e3000 - 0x5ef88000
TBOOT: discarding RAM above reserved regions: 0x5f888000 - 0x75a9f000
TBOOT: discarding RAM above reserved regions: 0x76bff000 - 0x76c00000
TBOOT: min_lo_ram: 0x0, max_lo_ram: 0x5d4e1000
TBOOT: min_hi_ram: 0x100000000, max_hi_ram: 0x47e000000
TBOOT: no LCP module found
TBOOT: SINIT ACM supports TCG compliant TPM 2.0 event log format,
tcg_event_log_format = 1 
TBOOT: TCG compliant TPM 2.0 event log descriptor:
TBOOT: 	 phys_addr = 0x76F30176
TBOOT: 	 allcoated_event_container_size = 0x2000 
TBOOT: 	 first_record_offset = 0x0 
TBOOT: 	 next_record_offset = 0x0 
TBOOT: heap_ext_data_element TYPE = 8 
TBOOT: heap_ext_data_element SIZE = 28 
TBOOT: os_sinit_data (@0x76f3517e, 0x88):
TBOOT: 	 version: 7
TBOOT: 	 flags: 1
TBOOT: 	 mle_ptab: 0x801000
TBOOT: 	 mle_size: 0x37000 (225280)
TBOOT: 	 mle_hdr_base: 0x1a960
TBOOT: 	 vtd_pmr_lo_base: 0x0
TBOOT: 	 vtd_pmr_lo_size: 0x5d400000
TBOOT: 	 vtd_pmr_hi_base: 0x100000000
TBOOT: 	 vtd_pmr_hi_size: 0x37e000000
TBOOT: 	 lcp_po_base: 0x0
TBOOT: 	 lcp_po_size: 0x0 (0)
TBOOT: 	 capabilities: 0x00000202
TBOOT: 	     rlp_wake_getsec: 0
TBOOT: 	     rlp_wake_monitor: 1
TBOOT: 	     ecx_pgtbl: 0
TBOOT: 	     stm: 0
TBOOT: 	     pcr_map_no_legacy: 0
TBOOT: 	     pcr_map_da: 0
TBOOT: 	     platform_type: 0
TBOOT: 	     max_phy_addr: 0
TBOOT: 	     tcg_event_log_format: 1
TBOOT: 	 efi_rsdt_ptr: 0x83fe00
TBOOT: 	 ext_data_elts[]:
TBOOT: 	 TCG EVENT_LOG_PTR:
TBOOT: 		       type: 8
TBOOT: 		       size: 28
TBOOT: 	 TCG Event Log Descrption:
TBOOT: 	     allcoated_event_container_size: 8192
TBOOT: 	                       EventsOffset: [0,0]
TBOOT: 			 No Event Log found.
TBOOT: setting MTRRs for acmod: base=0x76ed0000, size=0x20000, num_pages=32
TBOOT: The maximum allowed MTRR range size=16 Pages 
TBOOT: executing GETSEC[SENTER]...

-----Original Message-----
From: Haskins, Robert (US N-INCADENCE STRATEGIC SOLUTIONS CORPORATION) 
Sent: Monday, September 9, 2019 9:40 AM
To: 'gr...@id...' <gr...@id...>
Cc: 'tbo...@li...' <tbo...@li...>
Subject: RE: EXTERNAL: Re: [tboot-devel] GETSEC[SENTER]....and then reset

Thanks for your response! My responses are here:

1) We do have serial logging setup and working. I will work to get the logs
off the machine.
2) The platform is TPM2.
3) I am not sure what you mean by this question. Are you referring to index
0x1c10103? (see https://sourceforge.net/p/tboot/mailman/message/35551544/)
4) We are not implementing any launch control policy.

Thank you for your help!

-----Original Message-----
From: Dr. Greg <gr...@id...> 
Sent: Saturday, September 7, 2019 5:33 PM
To: Haskins, Robert (US N-INCADENCE STRATEGIC SOLUTIONS CORPORATION)
<rob...@lm...>
Cc: tbo...@li...
Subject: EXTERNAL: Re: [tboot-devel] GETSEC[SENTER]....and then reset

On Tue, Sep 03, 2019 at 08:37:06PM +0000, Haskins, Robert wrote:

Good afternoon Robert, I hope your weekend is going well.

> I have a Getac S410 G2 that I am trying to get TBOOT working on under 
> a vanilla RHEL 7.6 O/S with TBOOT 1.9.10. The TBOOT startup looks fine:
> 
> TXT.ERRCODE: 0x0
> 
> SINIT match on "the 6th_7th_gen_i5_i7-SINIT_79.bin" file
> 
> "last boot has no error"
> 
> Once it gets to GETSEC[SENTER], it just resets back to grub/startup
screen.
> 
> What am I doing wrong?

It could be a plethora of things.

It would be helpful to have logs from the first phase execution of tboot.
Since tboot is generating a hard platform reset you will need serial logging
or something else to capture the logs unless you are able to get memory
based logging to work.

Is the platform TPM1 or TPM2?  Given it is i6/i7 I'm assuming the latter.

Are the required TPM NVRAM locations configured?

Are you attempting to implement any type of launch control policy?

Logs and answers to the above questions should help get a conversation
started.

Have a good evening.

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...
----------------------------------------------------------------------------
--
"Sweeny's Law: The length of a progress report is inversely proportional  to
the amount of progress."

Re: [tboot-devel] EXTERNAL: Re: GETSEC[SENTER]....and then reset

[Haskins, R. <rob...@lm...>]

Thanks for your response! My responses are here:

1) We do have serial logging setup and working. I will work to get the logs
off the machine.
2) The platform is TPM2.
3) I am not sure what you mean by this question. Are you referring to index
0x1c10103? (see https://sourceforge.net/p/tboot/mailman/message/35551544/)
4) We are not implementing any launch control policy.

Thank you for your help!

-----Original Message-----
From: Dr. Greg <gr...@id...> 
Sent: Saturday, September 7, 2019 5:33 PM
To: Haskins, Robert (US N-INCADENCE STRATEGIC SOLUTIONS CORPORATION)
<rob...@lm...>
Cc: tbo...@li...
Subject: EXTERNAL: Re: [tboot-devel] GETSEC[SENTER]....and then reset

On Tue, Sep 03, 2019 at 08:37:06PM +0000, Haskins, Robert wrote:

Good afternoon Robert, I hope your weekend is going well.

> I have a Getac S410 G2 that I am trying to get TBOOT working on under 
> a vanilla RHEL 7.6 O/S with TBOOT 1.9.10. The TBOOT startup looks fine:
> 
> TXT.ERRCODE: 0x0
> 
> SINIT match on "the 6th_7th_gen_i5_i7-SINIT_79.bin" file
> 
> "last boot has no error"
> 
> Once it gets to GETSEC[SENTER], it just resets back to grub/startup
screen.
> 
> What am I doing wrong?

It could be a plethora of things.

It would be helpful to have logs from the first phase execution of tboot.
Since tboot is generating a hard platform reset you will need serial logging
or something else to capture the logs unless you are able to get memory
based logging to work.

Is the platform TPM1 or TPM2?  Given it is i6/i7 I'm assuming the latter.

Are the required TPM NVRAM locations configured?

Are you attempting to implement any type of launch control policy?

Logs and answers to the above questions should help get a conversation
started.

Have a good evening.

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...
----------------------------------------------------------------------------
--
"Sweeny's Law: The length of a progress report is inversely proportional  to
the amount of progress."

[tboot-devel] GETSEC[SENTER]....and then reset

[Haskins, R. <rob...@lm...>]

I have a Getac S410 G2 that I am trying to get TBOOT working on under a
vanilla RHEL 7.6 O/S with TBOOT 1.9.10. The TBOOT startup looks fine:

 

TXT.ERRCODE: 0x0

SINIT match on "the 6th_7th_gen_i5_i7-SINIT_79.bin" file

"last boot has no error"

 

Once it gets to GETSEC[SENTER], it just resets back to grub/startup screen.

 

What am I doing wrong?

 

 

 

 

[tboot-devel] [ANNOUNCE] Boot Security microconf at Linux Plumbers Conf, Sep 9-11

[Rich P. <pe...@gm...>]

https://www.linuxplumbersconf.org/blog/2019/system-boot-and-security-microconference-accepted-into-2019-linux-plumbers-conference/

System Boot and Security Microconference has been accepted into the 2019 Linux Plumbers Conference! Computer-system security is a topic that has gotten a lot of serious attention over the years, but there has not been anywhere near as much attention paid to the system firmware. But the firmware is also a target for those looking to wreak havoc on our systems. Firmware is now being developed with security in mind, but provides incomplete solutions. This microconference will focus on the security of the system especially from the time the system is powered on.

Expected topics for this year include:

TPMs
SRTM and DRTM
Intel TXT
AMD SKINIT
Attestation
UEFI Secure Boot
IMA
Intel SGX
Boot loaders
Firmware
OpenBMC

Re: [tboot-devel] Create LCP_PCONF_ELEMENT with TPM 2.0

[Dirk <xan...@gm...>]

Hi Lukasz,

Yes, I did provisioned TPM with the policy. And everything works fine. The
platform I used for test is Supermicro X11SDV-16C, TPM is Infineon SLB9670.

Regards,
Dirk

Hawrylko, Lukasz <luk...@in...> 於 2019年6月4日 週二 下午8:01寫道：

> Great, I will check your patch. Did you try to provision TPM with that
> policy and check if it works?
>
> Thanks,
> Lukasz
>
> -----Original Message-----
> *From*: Dirk <xan...@gm... <Dirk%20%3cx...@gm...%3e>>
> *To*: tbo...@li... <tbo...@li...
> <%22t...@li...%22%20%3ct...@li...%3e>
> >
> *Subject*: Re: [tboot-devel] Create LCP_PCONF_ELEMENT with TPM 2.0
> *Date*: Tue, 04 Jun 2019 10:33:37 +0800
>
> Hi Lukasz,
>
> I try to add PCONF element type support to lcptools-v2. It can worked with
> tpm2-tools
> to generate PCONF element by following commands.
>
> sudo tpm2_pcrlist -L sha256:0,1,2,3,4,5,6,7 --tcti=device | awk 'NR!=1
> {print $3}' | sed 's/0x//g' | sed -E 's/(.{2})/\1\ /g' > pcr
> lcp2_crtpolelt --create --type pconf --alg sha256 --pcr_hash sha256 --pcr
> 0,1,2,3,4,5,6,7 --ctrl 0x00 --out pconf.elt pcr
>
> Regards,
> Dirk
>
> Hawrylko, Lukasz <luk...@in...> 於 2019年6月3日 週一 下午5:23寫道：
>
> Hi Dirk
>
> I don't know if there any any official, public accessible tool for dumping
> PCRs. However structure of file required by lcp-gen2 is quite simple, it is
> described in util.py line 355.
>
> Thanks,
> Lukasz
>
> -----Original Message-----
> *From*: Dirk <xan...@gm... <Dirk%20%3cx...@gm...%3e>>
> *To*: tbo...@li... <tbo...@li...
> <%22t...@li...%22%20%3ct...@li...%3e>
> >
> *Subject*: Re: [tboot-devel] Create LCP_PCONF_ELEMENT with TPM 2.0
> *Date*: Tue, 28 May 2019 17:11:13 +0800
>
> Hi Lukasz,
>
> Thanks for the reply. I tried to run lcp-gen2 tool and found I can't
> create valid PCR dump
> file. In UserGuide.txt of lcp-gen2, mentioned that the PCR dump file can
> be created by
> PCRDump2. But I can't find the tool. Do you have any suggestion which tool
> I can use
> to dump the PCR file?
>
> Regards,
> Dirk
>
> Hawrylko, Lukasz <luk...@in...> 於 2019年5月27日 週一 下午2:24寫道：
>
> Hi Dirk
>
> LCP for TPM 2.0 is supported by lcp-gen2 tool. This tool allows to add
> PCONF element.
>
> Thanks,
> Lukasz
>
> -----Original Message-----
> From: Dirk <xan...@gm...>
> To: tbo...@li...
> Subject: [tboot-devel] Create LCP_PCONF_ELEMENT with TPM 2.0
> Date: Fri, 24 May 2019 10:13:27 +0800
>
> Hi,
>
> I am using tboot 1.9.9 and find there seems no way to create
> LCP_PCONF_ELEMENT
> with TPM 2.0. Tool lcp2_crtpolelt only support mle, custom, sbios and stm.
> Is there any
> way to create pconf element?
>
> Regards,
> Dirk
>
> _______________________________________________
> tboot-devel mailing list
> tbo...@li...
>
> https://lists.sourceforge.net/lists/listinfo/tboot-devel
>
>
> ---------------------------------------------------------------------
>
> *Intel Technology Poland sp. z o.o.*ul. S&#322owackiego 173 | 80-298
> Gda&#324sk | S&#261d Rejonowy Gda&#324sk P&#243&#322noc | VII Wydzia&#322
> Gospodarczy Krajowego Rejestru S&#261dowego - KRS 101882 | NIP
> 957-07-52-316 | Kapita&#322 zak&#322adowy 200.000 PLN.
>
> Ta wiadomo&#347&#263 wraz z za&#322&#261cznikami jest przeznaczona dla
> okre&#347lonego adresata i mo&#380e zawiera&#263 informacje poufne. W razie
> przypadkowego otrzymania tej wiadomo&#347ci, prosimy o powiadomienie
> nadawcy oraz trwa&#322e jej usuni&#281cie; jakiekolwiek przegl&#261danie
> lub rozpowszechnianie jest zabronione.
> This e-mail and any attachments may contain confidential material for the
> sole use of the intended recipient(s). If you are not the intended
> recipient, please contact the sender and delete all copies; any review or
> distribution by others is strictly prohibited.
>
> _______________________________________________
> tboot-devel mailing list
> tbo...@li...
> https://lists.sourceforge.net/lists/listinfo/tboot-devel
>
> _______________________________________________
>
> tboot-devel mailing list
>
> tbo...@li...
>
>
> https://lists.sourceforge.net/lists/listinfo/tboot-devel
>
>
> ---------------------------------------------------------------------
>
> *Intel Technology Poland sp. z o.o.*ul. S&#322owackiego 173 | 80-298
> Gda&#324sk | S&#261d Rejonowy Gda&#324sk P&#243&#322noc | VII Wydzia&#322
> Gospodarczy Krajowego Rejestru S&#261dowego - KRS 101882 | NIP
> 957-07-52-316 | Kapita&#322 zak&#322adowy 200.000 PLN.
>
> Ta wiadomo&#347&#263 wraz z za&#322&#261cznikami jest przeznaczona dla
> okre&#347lonego adresata i mo&#380e zawiera&#263 informacje poufne. W razie
> przypadkowego otrzymania tej wiadomo&#347ci, prosimy o powiadomienie
> nadawcy oraz trwa&#322e jej usuni&#281cie; jakiekolwiek przegl&#261danie
> lub rozpowszechnianie jest zabronione.
> This e-mail and any attachments may contain confidential material for the
> sole use of the intended recipient(s). If you are not the intended
> recipient, please contact the sender and delete all copies; any review or
> distribution by others is strictly prohibited.
>
> _______________________________________________
>
> tboot-devel mailing list
>
> tbo...@li...
>
>
> https://lists.sourceforge.net/lists/listinfo/tboot-devel
>
>
> ---------------------------------------------------------------------
>
> *Intel Technology Poland sp. z o.o.*ul. S&#322owackiego 173 | 80-298
> Gda&#324sk | S&#261d Rejonowy Gda&#324sk P&#243&#322noc | VII Wydzia&#322
> Gospodarczy Krajowego Rejestru S&#261dowego - KRS 101882 | NIP
> 957-07-52-316 | Kapita&#322 zak&#322adowy 200.000 PLN.
>
> Ta wiadomo&#347&#263 wraz z za&#322&#261cznikami jest przeznaczona dla
> okre&#347lonego adresata i mo&#380e zawiera&#263 informacje poufne. W razie
> przypadkowego otrzymania tej wiadomo&#347ci, prosimy o powiadomienie
> nadawcy oraz trwa&#322e jej usuni&#281cie; jakiekolwiek przegl&#261danie
> lub rozpowszechnianie jest zabronione.
> This e-mail and any attachments may contain confidential material for the
> sole use of the intended recipient(s). If you are not the intended
> recipient, please contact the sender and delete all copies; any review or
> distribution by others is strictly prohibited.
>
>

Re: [tboot-devel] Create LCP_PCONF_ELEMENT with TPM 2.0

[Hawrylko, L. <luk...@in...>]

--------------------------------------------------------------------

Intel Technology Poland sp. z o.o.
ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII Wydzial Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 957-07-52-316 | Kapital zakladowy 200.000 PLN.

Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresata i moze zawierac informacje poufne. W razie przypadkowego otrzymania tej wiadomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie; jakiekolwiek
przegladanie lub rozpowszechnianie jest zabronione.
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). If you are not the intended recipient, please contact the sender and delete all copies; any review or distribution by
others is strictly prohibited.

Re: [tboot-devel] Create LCP_PCONF_ELEMENT with TPM 2.0

[Dirk <xan...@gm...>]

Hi Lukasz,

I try to add PCONF element type support to lcptools-v2. It can worked with
tpm2-tools
to generate PCONF element by following commands.

sudo tpm2_pcrlist -L sha256:0,1,2,3,4,5,6,7 --tcti=device | awk 'NR!=1
{print $3}' | sed 's/0x//g' | sed -E 's/(.{2})/\1\ /g' > pcr
lcp2_crtpolelt --create --type pconf --alg sha256 --pcr_hash sha256 --pcr
0,1,2,3,4,5,6,7 --ctrl 0x00 --out pconf.elt pcr

Regards,
Dirk

Hawrylko, Lukasz <luk...@in...> 於 2019年6月3日 週一 下午5:23寫道：

> Hi Dirk
>
> I don't know if there any any official, public accessible tool for dumping
> PCRs. However structure of file required by lcp-gen2 is quite simple, it is
> described in util.py line 355.
>
> Thanks,
> Lukasz
>
> -----Original Message-----
> *From*: Dirk <xan...@gm... <Dirk%20%3cx...@gm...%3e>>
> *To*: tbo...@li... <tbo...@li...
> <%22t...@li...%22%20%3ct...@li...%3e>
> >
> *Subject*: Re: [tboot-devel] Create LCP_PCONF_ELEMENT with TPM 2.0
> *Date*: Tue, 28 May 2019 17:11:13 +0800
>
> Hi Lukasz,
>
> Thanks for the reply. I tried to run lcp-gen2 tool and found I can't
> create valid PCR dump
> file. In UserGuide.txt of lcp-gen2, mentioned that the PCR dump file can
> be created by
> PCRDump2. But I can't find the tool. Do you have any suggestion which tool
> I can use
> to dump the PCR file?
>
> Regards,
> Dirk
>
> Hawrylko, Lukasz <luk...@in...> 於 2019年5月27日 週一 下午2:24寫道：
>
> Hi Dirk
>
> LCP for TPM 2.0 is supported by lcp-gen2 tool. This tool allows to add
> PCONF element.
>
> Thanks,
> Lukasz
>
> -----Original Message-----
> From: Dirk <xan...@gm...>
> To: tbo...@li...
> Subject: [tboot-devel] Create LCP_PCONF_ELEMENT with TPM 2.0
> Date: Fri, 24 May 2019 10:13:27 +0800
>
> Hi,
>
> I am using tboot 1.9.9 and find there seems no way to create
> LCP_PCONF_ELEMENT
> with TPM 2.0. Tool lcp2_crtpolelt only support mle, custom, sbios and stm.
> Is there any
> way to create pconf element?
>
> Regards,
> Dirk
>
> _______________________________________________
> tboot-devel mailing list
> tbo...@li...
>
> https://lists.sourceforge.net/lists/listinfo/tboot-devel
>
>
> ---------------------------------------------------------------------
>
> *Intel Technology Poland sp. z o.o.*ul. S&#322owackiego 173 | 80-298
> Gda&#324sk | S&#261d Rejonowy Gda&#324sk P&#243&#322noc | VII Wydzia&#322
> Gospodarczy Krajowego Rejestru S&#261dowego - KRS 101882 | NIP
> 957-07-52-316 | Kapita&#322 zak&#322adowy 200.000 PLN.
>
> Ta wiadomo&#347&#263 wraz z za&#322&#261cznikami jest przeznaczona dla
> okre&#347lonego adresata i mo&#380e zawiera&#263 informacje poufne. W razie
> przypadkowego otrzymania tej wiadomo&#347ci, prosimy o powiadomienie
> nadawcy oraz trwa&#322e jej usuni&#281cie; jakiekolwiek przegl&#261danie
> lub rozpowszechnianie jest zabronione.
> This e-mail and any attachments may contain confidential material for the
> sole use of the intended recipient(s). If you are not the intended
> recipient, please contact the sender and delete all copies; any review or
> distribution by others is strictly prohibited.
>
> _______________________________________________
> tboot-devel mailing list
> tbo...@li...
> https://lists.sourceforge.net/lists/listinfo/tboot-devel
>
> _______________________________________________
>
> tboot-devel mailing list
>
> tbo...@li...
>
>
> https://lists.sourceforge.net/lists/listinfo/tboot-devel
>
>
> ---------------------------------------------------------------------
>
> *Intel Technology Poland sp. z o.o.*ul. S&#322owackiego 173 | 80-298
> Gda&#324sk | S&#261d Rejonowy Gda&#324sk P&#243&#322noc | VII Wydzia&#322
> Gospodarczy Krajowego Rejestru S&#261dowego - KRS 101882 | NIP
> 957-07-52-316 | Kapita&#322 zak&#322adowy 200.000 PLN.
>
> Ta wiadomo&#347&#263 wraz z za&#322&#261cznikami jest przeznaczona dla
> okre&#347lonego adresata i mo&#380e zawiera&#263 informacje poufne. W razie
> przypadkowego otrzymania tej wiadomo&#347ci, prosimy o powiadomienie
> nadawcy oraz trwa&#322e jej usuni&#281cie; jakiekolwiek przegl&#261danie
> lub rozpowszechnianie jest zabronione.
> This e-mail and any attachments may contain confidential material for the
> sole use of the intended recipient(s). If you are not the intended
> recipient, please contact the sender and delete all copies; any review or
> distribution by others is strictly prohibited.
>
>

Re: [tboot-devel] Create LCP_PCONF_ELEMENT with TPM 2.0

[Hawrylko, L. <luk...@in...>]

--------------------------------------------------------------------

Intel Technology Poland sp. z o.o.
ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII Wydzial Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 957-07-52-316 | Kapital zakladowy 200.000 PLN.

Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresata i moze zawierac informacje poufne. W razie przypadkowego otrzymania tej wiadomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie; jakiekolwiek
przegladanie lub rozpowszechnianie jest zabronione.
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). If you are not the intended recipient, please contact the sender and delete all copies; any review or distribution by
others is strictly prohibited.

Re: [tboot-devel] Create LCP_PCONF_ELEMENT with TPM 2.0

[Dirk <xan...@gm...>]

Hi Lukasz,

Thanks for the reply. I tried to run lcp-gen2 tool and found I can't create
valid PCR dump
file. In UserGuide.txt of lcp-gen2, mentioned that the PCR dump file can be
created by
PCRDump2. But I can't find the tool. Do you have any suggestion which tool
I can use
to dump the PCR file?

Regards,
Dirk

Hawrylko, Lukasz <luk...@in...> 於 2019年5月27日 週一 下午2:24寫道：

> Hi Dirk
>
> LCP for TPM 2.0 is supported by lcp-gen2 tool. This tool allows to add
> PCONF element.
>
> Thanks,
> Lukasz
>
> -----Original Message-----
> From: Dirk <xan...@gm...>
> To: tbo...@li...
> Subject: [tboot-devel] Create LCP_PCONF_ELEMENT with TPM 2.0
> Date: Fri, 24 May 2019 10:13:27 +0800
>
> Hi,
>
> I am using tboot 1.9.9 and find there seems no way to create
> LCP_PCONF_ELEMENT
> with TPM 2.0. Tool lcp2_crtpolelt only support mle, custom, sbios and stm.
> Is there any
> way to create pconf element?
>
> Regards,
> Dirk
>
> _______________________________________________
> tboot-devel mailing list
> tbo...@li...
>
> https://lists.sourceforge.net/lists/listinfo/tboot-devel
>
>
> ---------------------------------------------------------------------
>
> *Intel Technology Poland sp. z o.o.*ul. S&#322owackiego 173 | 80-298
> Gda&#324sk | S&#261d Rejonowy Gda&#324sk P&#243&#322noc | VII Wydzia&#322
> Gospodarczy Krajowego Rejestru S&#261dowego - KRS 101882 | NIP
> 957-07-52-316 | Kapita&#322 zak&#322adowy 200.000 PLN.
>
> Ta wiadomo&#347&#263 wraz z za&#322&#261cznikami jest przeznaczona dla
> okre&#347lonego adresata i mo&#380e zawiera&#263 informacje poufne. W razie
> przypadkowego otrzymania tej wiadomo&#347ci, prosimy o powiadomienie
> nadawcy oraz trwa&#322e jej usuni&#281cie; jakiekolwiek przegl&#261danie
> lub rozpowszechnianie jest zabronione.
> This e-mail and any attachments may contain confidential material for the
> sole use of the intended recipient(s). If you are not the intended
> recipient, please contact the sender and delete all copies; any review or
> distribution by others is strictly prohibited.
>
> _______________________________________________
> tboot-devel mailing list
> tbo...@li...
> https://lists.sourceforge.net/lists/listinfo/tboot-devel
>

Re: [tboot-devel] Create LCP_PCONF_ELEMENT with TPM 2.0

[Hawrylko, L. <luk...@in...>]

Hi Dirk

LCP for TPM 2.0 is supported by lcp-gen2 tool. This tool allows to add PCONF element.

Thanks,
Lukasz

-----Original Message-----
From: Dirk <xan...@gm...>
To: tbo...@li...
Subject: [tboot-devel] Create LCP_PCONF_ELEMENT with TPM 2.0
Date: Fri, 24 May 2019 10:13:27 +0800

Hi,

I am using tboot 1.9.9 and find there seems no way to create LCP_PCONF_ELEMENT
with TPM 2.0. Tool lcp2_crtpolelt only support mle, custom, sbios and stm. Is there any
way to create pconf element?

Regards,
Dirk

_______________________________________________
tboot-devel mailing list
tbo...@li...

https://lists.sourceforge.net/lists/listinfo/tboot-devel

[tboot-devel] Create LCP_PCONF_ELEMENT with TPM 2.0

[Dirk <xan...@gm...>]

Hi,

I am using tboot 1.9.9 and find there seems no way to create
LCP_PCONF_ELEMENT
with TPM 2.0. Tool lcp2_crtpolelt only support mle, custom, sbios and stm.
Is there any
way to create pconf element?

Regards,
Dirk

Re: [tboot-devel] tboot test coverage

[Hawrylko, L. <luk...@in...>]

Hi Rich

Sorry, but I didn't get your question, could you explain it a little
more? You can look at TBOOT Live Image (
https://platformsw.intel.com/CollateralDownload.aspx?key=COL.1021528&action=edit
) or prepare something similar by yourself. It is Linux distro with
TBOOT and tools required for testing Intel TXT that can be run from USB
pendrive.

Thanks,
Lukasz

-----Original Message-----
From: Rich Persaud <pe...@gm...>
To: tbo...@li...
Subject: [tboot-devel] tboot test coverage
Date: Wed, 20 Mar 2019 14:34:42 -0400

What's the best open-source test suite to compare multiple versions of
tboot on one device, or one version of tboot on multiple devices?  This
comparison is helpful to differentiate between hardware, firmware and
tboot issues.

Rich

_______________________________________________
tboot-devel mailing list
tbo...@li...

https://lists.sourceforge.net/lists/listinfo/tboot-devel