tboot-devel — Developer support

[tboot-devel] tboot test coverage

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

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

Re: [tboot-devel] readme on tboot

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

> On Jan 11, 2019, at 11:42, Mat <alt...@gm...> wrote:
> 
> Can anyone else explain in simple words the difference between Secure boot and Trusted boot.

UEFI Secure Boot has roots in the Microsoft PC ecosystem, it was later adapted to Linux, see Matthew Garrett's blog:  http://mjg59.dreamwidth.org/9844.html and Bootlin ELC 2018 slides: https://bootlin.com/pub/conferences/2018/elc/josserand-schulz-secure-boot/josserand-schulz-secure-boot.pdf

Here is my intro to trusted boot, but Greg's explanation is more approachable (it would make a good article!):  https://www.linux.com/blog/event/elce/2017/10/device-we-trust-measure-twice-compute-once-xen-linux-tpm-20-and-txt

You could also watch some talks on boot integrity, e.g. Hudson, Smith:
https://www.platformsecuritysummit.com/2018/topic/boot/

Rich

Re: [tboot-devel] readme on tboot

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

Can anyone else explain in simple words the difference between Secure boot
and Trusted boot.

Thank you Greg for your continued elaboration.

On Thu, Jan 10, 2019 at 6:28 PM Dr. Greg <gr...@en...> wrote:

> On Tue, Jan 08, 2019 at 03:02:32PM -0800, Mat wrote:
>
> Good evening, I hope the week has gone well.
>
> > There are firmware based secure boot using fTPM secure partitioning and
> > more.
> >
> > Some chipset vendors also support secure boot natively.
>
> If you are talking fTPM I assume you are referring to ARM hardware.
> Platform Trust Technology (PTT) would be the equivalent on Intel
> which, presumably, runs on the Management Engine rather then in a
> TrustZone TEE which is where the fTPM is implemented on ARM.
>
> So if you have fTPM support and the ARM platform is UEFI I'm assuming
> the OEM has wired up their hardware to implement the UEFI Secure Boot
> standard.
>
> > 1. Is there a cpu architecture-neutral way to implement
> > secure/trusted boot.
>
> I think to assist the conversation it is important to differentiate
> between Secure Boot and Trusted Boot, they are entirely different
> concepts.
>
> 'Secure Boot' implies that the firmware will verify that the operating
> system image that is being loaded has been signed with an asymmetric
> key that it has access to.  The security predicate that you are
> operating with is a guarantee that at system boot time an operating
> system image with known provenance was loaded.
>
> 'Trusted Boot' is a much broader security guarantee that has no
> equivalent in the ARM world, as far as I know.  In the Intel world,
> where it is implemented as Trusted eXecution Technology (TXT), it
> provides a guarantee that an authenticated/signed code module was used
> to initialize a root of trust that a system integrity predicate can be
> constructed on.
>
> The Intel Software Development Manual (SDM) has an entire section on
> how TXT works.  The short description is that Intel supplies system
> initialization code in the form of an Authenticated Code Module (ACM).
> Special processor instructions (GETSEC leaf instructions) execute this
> module after verifying the signature on the module and further
> verifying that the processor and chipset are in a known state.
>
> The code in the ACM runs at a privilege level that allows access to a
> hardware TPM that is unavailable at any other time.  The ACM clears
> Platform Configuration Registers (PCR's) and then seeds them through
> linear extension with checksums over various critical aspects of the
> system such as the firmware and its configuration.  The ACM also can
> implement a launch control policy that can be used to verify the
> system is in a specific state before control is returned to the
> security hypervisor (tboot) which continues on with the system boot.
>
> As the operating system continues forward it has an assurance that the
> hardware TPM has been initialized to a precisely known state.  The
> strategy for a 'trusted system' is to extend the PCR's with values
> derived from operational elements of the system, such as the
> cryptographic hashes of executables run by the operating system.
>
> So that is how 'Trusted Boot' works.
>
> If you have fTPM support and the ARM platform is UEFI and the OEM has
> wired up their hardware to implement the UEFI Secure Boot standard you
> would be in a position to implement 'Secure Boot', ie. a signed
> operating system image.
>
> The platform vendor should have options available through the BIOS to
> install a custom platform key.  The default will undoubtedly be the
> Microsoft signing key.
>
> You can install a custom signing key and then sign your operating
> system image with the private portion of the key.  At that point the
> firmware will only load an operating system whose signature matches
> that which is authenticated by the public/private keypair you have
> loaded.
>
> The issue is that anything can happen after that point.  With 'Trusted
> Boot' you are in a position to detect that but 'Secure Boot' doesn't
> provide the ability to do that by default.  You do have access to a
> TPM (fTPM) so with a bit of effort you could construct something
> similar but it will require a bit of code rolling.  Without chipset
> support you will not be able to implement the type of guarantee that
> is available with TXT.
>
> Given that Secure Boot is a UEFI standard it would be the closest
> thing possible to a cpu/architecture independent method of
> establishing some type of security construct.  Extending a security
> guarantee beyond boot is a decidedly non-trivial process.
>
> > 2. Assuming an internet facing router(without secure/trusted boot)
> > is hardened enough with basic security measures, what are different
> > attack vectors to install malicious code on the router.
>
> If it was easy to predict that we wouldn't have the cybersecurity
> challenge that we have on our hands.... :-) The whole concept of
> 0-day's is that they are a class of vulnerability that no one knew
> existed.
>
> The solution to that is allowing the platform to engage in only known
> behaviors.  The goal of 'Trusted Boot', or something equivalent built
> on top of Secure Boot, is to have confidence that the current behavior
> of a platform could only have been achieved through a trajectory path
> of known behaviors, originating from a known and trusted origin point.
>
> A methodology for doing that is certainly not something that is
> codified in any type of cpu or architecturally independent manner.
>
> > -C
>
> Hopefully the above is helpful.
>
> Good luck with your efforts.
>
> Dr. Greg
>
> As always,
> Dr. G.W. Wettstein, Ph.D.   Enjellic Systems Development, LLC.
> 4206 N. 19th Ave.           Specializing in information infra-structure
> Fargo, ND  58102            development.
> PH: 701-281-1686
> FAX: 701-281-3949           EMAIL: gr...@en...
>
> ------------------------------------------------------------------------------
> "Simplicity is prerequisite for reliability."
>                                 -- Edsger W. Dijkstra
>

Re: [tboot-devel] readme on tboot

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

On Tue, Jan 08, 2019 at 03:02:32PM -0800, Mat wrote:

Good evening, I hope the week has gone well.

> There are firmware based secure boot using fTPM secure partitioning and
> more.
>
> Some chipset vendors also support secure boot natively.

If you are talking fTPM I assume you are referring to ARM hardware.
Platform Trust Technology (PTT) would be the equivalent on Intel
which, presumably, runs on the Management Engine rather then in a
TrustZone TEE which is where the fTPM is implemented on ARM.

So if you have fTPM support and the ARM platform is UEFI I'm assuming
the OEM has wired up their hardware to implement the UEFI Secure Boot
standard.

> 1. Is there a cpu architecture-neutral way to implement
> secure/trusted boot.

I think to assist the conversation it is important to differentiate
between Secure Boot and Trusted Boot, they are entirely different
concepts.

'Secure Boot' implies that the firmware will verify that the operating
system image that is being loaded has been signed with an asymmetric
key that it has access to.  The security predicate that you are
operating with is a guarantee that at system boot time an operating
system image with known provenance was loaded.

'Trusted Boot' is a much broader security guarantee that has no
equivalent in the ARM world, as far as I know.  In the Intel world,
where it is implemented as Trusted eXecution Technology (TXT), it
provides a guarantee that an authenticated/signed code module was used
to initialize a root of trust that a system integrity predicate can be
constructed on.

The Intel Software Development Manual (SDM) has an entire section on
how TXT works.  The short description is that Intel supplies system
initialization code in the form of an Authenticated Code Module (ACM).
Special processor instructions (GETSEC leaf instructions) execute this
module after verifying the signature on the module and further
verifying that the processor and chipset are in a known state.

The code in the ACM runs at a privilege level that allows access to a
hardware TPM that is unavailable at any other time.  The ACM clears
Platform Configuration Registers (PCR's) and then seeds them through
linear extension with checksums over various critical aspects of the
system such as the firmware and its configuration.  The ACM also can
implement a launch control policy that can be used to verify the
system is in a specific state before control is returned to the
security hypervisor (tboot) which continues on with the system boot.

As the operating system continues forward it has an assurance that the
hardware TPM has been initialized to a precisely known state.  The
strategy for a 'trusted system' is to extend the PCR's with values
derived from operational elements of the system, such as the
cryptographic hashes of executables run by the operating system.

So that is how 'Trusted Boot' works.

If you have fTPM support and the ARM platform is UEFI and the OEM has
wired up their hardware to implement the UEFI Secure Boot standard you
would be in a position to implement 'Secure Boot', ie. a signed
operating system image.

The platform vendor should have options available through the BIOS to
install a custom platform key.  The default will undoubtedly be the
Microsoft signing key.

You can install a custom signing key and then sign your operating
system image with the private portion of the key.  At that point the
firmware will only load an operating system whose signature matches
that which is authenticated by the public/private keypair you have
loaded.

The issue is that anything can happen after that point.  With 'Trusted
Boot' you are in a position to detect that but 'Secure Boot' doesn't
provide the ability to do that by default.  You do have access to a
TPM (fTPM) so with a bit of effort you could construct something
similar but it will require a bit of code rolling.  Without chipset
support you will not be able to implement the type of guarantee that
is available with TXT.

Given that Secure Boot is a UEFI standard it would be the closest
thing possible to a cpu/architecture independent method of
establishing some type of security construct.  Extending a security
guarantee beyond boot is a decidedly non-trivial process.

> 2. Assuming an internet facing router(without secure/trusted boot)
> is hardened enough with basic security measures, what are different
> attack vectors to install malicious code on the router.

If it was easy to predict that we wouldn't have the cybersecurity
challenge that we have on our hands.... :-) The whole concept of
0-day's is that they are a class of vulnerability that no one knew
existed.

The solution to that is allowing the platform to engage in only known
behaviors.  The goal of 'Trusted Boot', or something equivalent built
on top of Secure Boot, is to have confidence that the current behavior
of a platform could only have been achieved through a trajectory path
of known behaviors, originating from a known and trusted origin point.

A methodology for doing that is certainly not something that is
codified in any type of cpu or architecturally independent manner.

> -C

Hopefully the above is helpful.

Good luck with your efforts.

Dr. Greg

As always,
Dr. G.W. Wettstein, Ph.D.   Enjellic Systems Development, LLC.
4206 N. 19th Ave.           Specializing in information infra-structure
Fargo, ND  58102            development.
PH: 701-281-1686
FAX: 701-281-3949           EMAIL: gr...@en...
------------------------------------------------------------------------------
"Simplicity is prerequisite for reliability."
                                -- Edsger W. Dijkstra

Re: [tboot-devel] readme on tboot

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

There are firmware based secure boot using fTPM secure partitioning and
more.

Some chipset vendors also support secure boot natively.

1. Is there a cpu architecture-neutral way to implement secure/trusted boot.
2. Assuming an internet facing router(without secure/trusted boot) is
hardened enough with basic security measures, what are different attack
vectors to install malicious code on the router.

-C
On Tue, Jan 8, 2019 at 1:53 AM Dr. Greg <gr...@en...> wrote:

> On Mon, Jan 07, 2019 at 09:25:55PM -0800, Mat wrote:
>
> Good day again.
>
> > So, what is the criterion to implement Secure boot or Trusted boot.
> > Where are the instructions to implement either?  What are some
> > minimum pre-requisites on existing Router (say) to implement either.
>
> As I noted in my previous e-mail, the most fundamental issue is
> hardware support for either Secure Boot or TXT.
>
> If you choose to use Secure Boot I doubt if your routers are running
> Windows so you will need to install a platform key that you hold the
> private key for.  You will use that private key to sign whatever
> operating system image you will be booting.  There are any number of
> resources available on the WEB that describe how to create and install
> a custom platform key.
>
> Implementing TXT is a bit more involved.  At a minimum you need to
> reconfigure the boot process to use tboot as the primary kernel image
> and to specify the kernel as a multiboot module along with its
> initrd/initramfs image as an additional module.
>
> This will produce a system that boots the kernel into a known hardware
> state.  You will, at a minimum, want to have a Launch Policy (LP) that
> specifies the desired signature (hash) of the kernel to verify the
> kernel that booted is the one you wanted to boot.
>
> A more sophisticated implementation will also want to include
> verification of a hardware quote over TPM based Platform Configuration
> Registers (PCR's) that verify a known state of the hardware/firmware
> that the known kernel image is booting into.
>
> As I mentioned in my previous e-mail, all of this gets you to a point
> where you have a known operating system image running.  Verifying the
> ongoing status of the platform requires that an integrity verification
> architecture be built upon this root of trust.
>
> The Linux Integrity Measurement Architecture (IMA) is built to sit on
> top of a TXT based boot and provide hardware based integrity logging.
> I haven't looked at the code in a while but I believe there has been
> some work to link the integrity chain it provides to a Secure Boot
> root of trust as well.
>
> In order to implement a competent security statement there has to be
> some type of attestation by an external verifying party as to the
> state of the integrity logs.
>
> In either the case of TXT or Secure Boot, a correct solution involves
> more then invoking some instructions or commands.  Constructing a high
> security assurance platform requires a fair amount of platform
> engineering and architecture expertise.  Personally I don't think it
> is the domain of standard Linux distributions given how large and
> complex they have become.
>
> Hopefully the above information is helpful.
>
> Dr. Greg
>
> As always,
> Dr. Greg Wettstein, Ph.D, Worker
> IDfusion, LLC
> 4206 N. 19th Ave.           Implementing measured information privacy
> Fargo, ND  58102            and integrity architectures.
> PH: 701-281-1686
> FAX: 701-281-3949           EMAIL: gw...@id...
>
> ------------------------------------------------------------------------------
> "I can only provide the information, I can't make you hear it."
>                                 -- Shelley Bainter
>

Re: [tboot-devel] readme on tboot

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

On Mon, Jan 07, 2019 at 09:25:55PM -0800, Mat wrote:

Good day again.

> So, what is the criterion to implement Secure boot or Trusted boot.
> Where are the instructions to implement either?  What are some
> minimum pre-requisites on existing Router (say) to implement either.

As I noted in my previous e-mail, the most fundamental issue is
hardware support for either Secure Boot or TXT.

If you choose to use Secure Boot I doubt if your routers are running
Windows so you will need to install a platform key that you hold the
private key for.  You will use that private key to sign whatever
operating system image you will be booting.  There are any number of
resources available on the WEB that describe how to create and install
a custom platform key.

Implementing TXT is a bit more involved.  At a minimum you need to
reconfigure the boot process to use tboot as the primary kernel image
and to specify the kernel as a multiboot module along with its
initrd/initramfs image as an additional module.

This will produce a system that boots the kernel into a known hardware
state.  You will, at a minimum, want to have a Launch Policy (LP) that
specifies the desired signature (hash) of the kernel to verify the
kernel that booted is the one you wanted to boot.

A more sophisticated implementation will also want to include
verification of a hardware quote over TPM based Platform Configuration
Registers (PCR's) that verify a known state of the hardware/firmware
that the known kernel image is booting into.

As I mentioned in my previous e-mail, all of this gets you to a point
where you have a known operating system image running.  Verifying the
ongoing status of the platform requires that an integrity verification
architecture be built upon this root of trust.

The Linux Integrity Measurement Architecture (IMA) is built to sit on
top of a TXT based boot and provide hardware based integrity logging.
I haven't looked at the code in a while but I believe there has been
some work to link the integrity chain it provides to a Secure Boot
root of trust as well.

In order to implement a competent security statement there has to be
some type of attestation by an external verifying party as to the
state of the integrity logs.

In either the case of TXT or Secure Boot, a correct solution involves
more then invoking some instructions or commands.  Constructing a high
security assurance platform requires a fair amount of platform
engineering and architecture expertise.  Personally I don't think it
is the domain of standard Linux distributions given how large and
complex they have become.

Hopefully the above information is helpful.

Dr. Greg

As always,
Dr. Greg Wettstein, Ph.D, Worker
IDfusion, LLC
4206 N. 19th Ave.           Implementing measured information privacy
Fargo, ND  58102            and integrity architectures.
PH: 701-281-1686
FAX: 701-281-3949           EMAIL: gw...@id...
------------------------------------------------------------------------------
"I can only provide the information, I can't make you hear it."
                                -- Shelley Bainter

Re: [tboot-devel] readme on tboot

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

So, what is the criterion to implement Secure boot or Trusted boot.
Where are the instructions to implement either?
What are some minimum pre-requisites on existing Router (say) to implement
either.

On Mon, Jan 7, 2019 at 1:54 AM Dr. Greg <gr...@en...> wrote:

> On Sat, Jan 05, 2019 at 07:22:36PM -0800, Mat wrote:
>
> Good morning, I hope the week is starting well for everyone.
>
> > How would a device vendor use tboot to implement secure/trusted boot
> > on their networking devices like routers and switches?
> >
> > If someone can also clarify diff between secure boot and trusted
> > boot, when to use what.
>
> Let me invert the order of these questions and then expand on the
> former.
>
> Simplistically, secure boot is a firmware based solution for
> implementing cryptographically signed boot images.  A public key is
> available to the firmware that is used to authenticate the signature
> on a kernel image.  This provides a platform security architect an
> assurance that the system has been booted with a known state of an
> operating system image.
>
> TBOOT is the software component of a larger body of technology
> referred to as Trusted eXecution Technology (TXT).  It is a cohort of
> processor/chipset/hardware/software technology that provides a
> framework for validating that the platform is in a known state up to
> and through the operating system load.
>
> The intent of both technologies is to provide a 'root of trust' that
> platform architects can use to create inferences (attestations) about
> the integrity of an application stack running on a platform.
> TXT/tboot provides a more comprehensive guarantee as to the quality of
> that trust root.
>
> How to effectively leverage this 'root of trust' to create a secure
> device is a large, complex and arguably immature topic.  I direct
> engineering for a company that uses both of these technologies, and to
> a much larger extent Intel's Software Guard Extensions (SGX), to
> provide platform security guarantees for devices such as you describe.
> We refer, generically, to these types of devices as Intelligent
> Network Endpoint Devices (INED's).
>
> We use a trust root to support something we refer to as Autonomous
> Introspection (the 'other' AI).  The notion of AI involves running a
> modeling engine that can make deterministic decisions about whether or
> not the platform is operating in a manner consistent with the intent
> of the developer.  If not, the introspection engine can take very
> precise and targeted actions in order to discipline the context of
> execution that is attempting to engage in an extra-dimensional
> behavior.
>
> Technically, neither TXT/Tboot or Secure Boot, make a platform
> 'secure'.  What they provide is a guarantee that there is a known
> 'good' state on which a security architecture can be crafted.
>
> > -c
>
> Hopefully the above is a helpful summary.  We can go into more detail
> on any of these issues if you have more specific questions.
>
> Have a good remainder of the week.
>
> Dr. Greg
>
> As always,
> Dr. G.W. Wettstein, Ph.D.   Enjellic Systems Development, LLC.
> 4206 N. 19th Ave.           Specializing in information infra-structure
> Fargo, ND  58102            development.
> PH: 701-281-1686
> FAX: 701-281-3949           EMAIL: gr...@en...
>
> ------------------------------------------------------------------------------
> "Human beings, who are almost unique in having the ability to learn
>  from the experience of others, are also remarkable for their apparent
>  disinclination to do so."
>                                 -- Douglas Adams
>

Re: [tboot-devel] readme on tboot

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

On Sat, Jan 05, 2019 at 07:22:36PM -0800, Mat wrote:

Good morning, I hope the week is starting well for everyone.

> How would a device vendor use tboot to implement secure/trusted boot
> on their networking devices like routers and switches?
>
> If someone can also clarify diff between secure boot and trusted
> boot, when to use what.

Let me invert the order of these questions and then expand on the
former.

Simplistically, secure boot is a firmware based solution for
implementing cryptographically signed boot images.  A public key is
available to the firmware that is used to authenticate the signature
on a kernel image.  This provides a platform security architect an
assurance that the system has been booted with a known state of an
operating system image.

TBOOT is the software component of a larger body of technology
referred to as Trusted eXecution Technology (TXT).  It is a cohort of
processor/chipset/hardware/software technology that provides a
framework for validating that the platform is in a known state up to
and through the operating system load.

The intent of both technologies is to provide a 'root of trust' that
platform architects can use to create inferences (attestations) about
the integrity of an application stack running on a platform.
TXT/tboot provides a more comprehensive guarantee as to the quality of
that trust root.

How to effectively leverage this 'root of trust' to create a secure
device is a large, complex and arguably immature topic.  I direct
engineering for a company that uses both of these technologies, and to
a much larger extent Intel's Software Guard Extensions (SGX), to
provide platform security guarantees for devices such as you describe.
We refer, generically, to these types of devices as Intelligent
Network Endpoint Devices (INED's).

We use a trust root to support something we refer to as Autonomous
Introspection (the 'other' AI).  The notion of AI involves running a
modeling engine that can make deterministic decisions about whether or
not the platform is operating in a manner consistent with the intent
of the developer.  If not, the introspection engine can take very
precise and targeted actions in order to discipline the context of
execution that is attempting to engage in an extra-dimensional
behavior.

Technically, neither TXT/Tboot or Secure Boot, make a platform
'secure'.  What they provide is a guarantee that there is a known
'good' state on which a security architecture can be crafted.

> -c

Hopefully the above is a helpful summary.  We can go into more detail
on any of these issues if you have more specific questions.

Have a good remainder of the week.

Dr. Greg

As always,
Dr. G.W. Wettstein, Ph.D.   Enjellic Systems Development, LLC.
4206 N. 19th Ave.           Specializing in information infra-structure
Fargo, ND  58102            development.
PH: 701-281-1686
FAX: 701-281-3949           EMAIL: gr...@en...
------------------------------------------------------------------------------
"Human beings, who are almost unique in having the ability to learn
 from the experience of others, are also remarkable for their apparent
 disinclination to do so."
                                -- Douglas Adams

[tboot-devel] readme on tboot

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

How would a device vendor use tboot to implement secure/trusted boot on
their networking devices like routers and switches?

If someone can also clarify diff between secure boot and trusted boot, when
to use what.
-c

Re: [tboot-devel] Tboot on TPM2.0 (Intel NUC5i5MYHE) on Ubuntu 16.04 LTS

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

On Mon, Dec 10, 2018 at 09:41:36PM +0000, Rayees Shamsuddin wrote:

> Hi tboot team,

Good morning Rayees, I hope this note finds your week going well.

> I was wondering if I missed getting response due to the
> holidays. Hence bumping this one up.  I would appreciate any input
> or pointers on setting up the LCP and VLP for TPM2.0.

We saw your original mail go by on the list but were swamped at the
time.  I was able to grab a little time this evening to look back at
our notes.

We committed a lot of engineering resources to getting TPM2/TXT based
boots working a couple of years ago and identified a number of issues
that prevented the stock tboot implementation from even functioning on
these systems.  A lot of that work ended up provoking various patches
to tboot that left the package with some hope of functioning on these
systems.  I would advocate only using the most recent tboot source
release.

The reference platform we were working on the time was the Broadwell
based NUC you are using.  We had the optional serial cable installed
with the DB-9 male port attached to another Linux machine with a null
model cable.  We had that working in order to get serial logging from
tboot using the following tboot definition:

kernel /boot/tboot.gz logging=serial,memory,vga vga_delay=1 serial=115200 extpol=sha256

We were able to get a functional boot with an LCP_ANY policy written
to NVRAM location 0x1400001.  We didn't take the work beyond that
point since we started focusing on Skylake based platforms that we
were never able to get working, at least on Gigabyte based boards,
secondary to improper TXT TPM2 NVRAM provisioning by the board OEM.

I see from your previous e-mail that you are attempting to use a
signed LCP defining the permitted tboot command-line.  The jury could
still be very much out whether or not the Intel supplied SINIT is even
able to process those correctly.  Before you even attempt that we
would recommend that you get a functional tboot launch with a simply
LCP_ANY policy.  We can at least confirm that works on the Broadwell
NUC you are working on.

At this point in time the logs you posted are indicating that the
policy isn't even getting read out of TPM2 NVRAM.  We noted the
following NVram definition from your previous e-mail:

tpm2_nvdefine -x 0x1400001 -a 0x40000001 -s 70 -t 0x004000A -P new (attribute of 0x204000A gave error 'Invalid PO Attr')

We are currently demonstrating that the Broadwell NUC is properly
loading the LCP_ANY policy with the following PO NVRAM attribute
specification:

0x2004000a

Which translates to the following attribute bits being set:

OWNERWRITE
POLICYWRITE
AUTHREAD
WRITTEN

There is an architectural defect in the Broadwell TXT platforms that
causes tboot to fail when the platform owner attribute is configured
in a manner consistent with the TXT Software Developer's Manual.

Specifically, the NO_DA attribute bit must be cleared in the NVram
attribute definition on these platforms.

Here is a dump of the platform owner NVram definition on a Broadwell
NUC with a functional LCP_ANY policy:

---------------------------------------------------------------------------
Attributes: 0x2004000a
	OWNERWRITE
	POLICYWRITE
	AUTHREAD
	WRITTEN
Contents of NVram index: 0x1400001/20971521
00000016: 00 03 0b 00 01 00 00 00 00 00 00 00 00 00 00 00 ................
00000032: 00 00 00 00 00 00 02 00 00 00 00 00 c8 00 08 30 ...............0
00000048: 00 00 08 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000064: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000070: 00 00 00 00 00 00                               ................
---------------------------------------------------------------------------

The above output is from custom TPM2 utilities that we built based on
Ken Goldman's TSS2 library.

If you can get the NVram index location configured with those
attributes and loaded with that binary sequence we are pretty
confident the NUC should successfully complete a measured launch
implementing an LCP_ANY policy.

Once you have that working you will have a point from which you can
work with functional confidence in order to get the hash of your
policy list written to NVram to see how SINIT copes with that.

> Thanks and Regards
> Rayees Shamsuddin

I hope the above information is helpful.

We would be interested in learning whether or not you are able to get
anything more sophisticated then LCP_ANY working.  We are largely
consumed with SGX engineering at this time but anticipate returning to
TXT for a pending project.

Good luck with your work, best wishes for a productive week.

Dr. Greg

As always,
Dr. G.W. Wettstein, Ph.D.   Enjellic Systems Development, LLC.
4206 N. 19th Ave.           Specializing in information infra-structure
Fargo, ND  58102            development.
PH: 701-281-1686
FAX: 701-281-3949           EMAIL: gr...@en...
------------------------------------------------------------------------------
"I had far rather walk, as I do, in daily terror of eternity, than feel
 that this was only a children's game in which all of the contestants
 would get equally worthless prizes in the end."
                                -- T. S. Elliot

Re: [tboot-devel] Tboot on TPM2.0 (Intel NUC5i5MYHE) on Ubuntu 16.04 LTS

[Rayees S. <Ray...@in...>]

Hi tboot team,

I was wondering if I missed getting response due to the holidays. Hence bumping this one up.
I would appreciate any input or pointers on setting up the LCP and VLP for TPM2.0.

Thanks and Regards
Rayees Shamsuddin


_____________________________________________
From: Rayees Shamsuddin
Sent: Monday, November 26, 2018 2:02 PM
To: tbo...@li...
Subject: Tboot on TPM2.0 (Intel NUC5i5MYHE) on Ubuntu 16.04 LTS


Hi tboot devs,

I am trying to get tboot to work with TPM2.0 on an Intel NUC5i5MYHE on Ubuntu 16.04. I am able to boot with tboot using the default policy. However when I try to define my own policy, it fails to read the policy from the NV and uses the default policy. I have looked up the different posts on this list, but couldn't figure out the process exactly. I would appreciate any help to understand tboot and get it working. My end goal is to be replicate a policy for TPM2.0 similar to one suggested in https://wiki.gentoo.org/wiki/Trusted_Boot

These are the commands I used:
tpm2_takeownership -o new -e new -l new
tpm2_nvdefine -x 0x1400001 -a 0x40000001 -s 70 -t 0x004000A -P new (attribute of 0x204000A gave error 'Invalid PO Attr')
lcp2_mlehash --create --alg sha256 --cmdline "logging=serial,memory extpol=sha256" /boot/tboot.gz > tboot_hash
lcp2_crtpolelt --create --type mle --alg sha256 --ctrl 0x00 --minver 0 --out tbootmle.elt tboot_hash
lcp2_crtpollist --create --out list_unsig.lst tbootmle.elt
cp list_unsig.lst list_sig.lst
openssl genrsa -out privkey.pem 2048
openssl rsa -pubout -in privkey.pem -out pubkey.pem
lcp2_crtpollist --sign 0x8 --sigalg rsa --pub pubkey.pem --priv privkey.pem --out list_sig.lst
lcp2_crtpol --create --type list --pol list.pol --alg sha256 --sign 0x8 --data list.data list_sig.lst
sudo cp list.data /boot
tpm2_nvwrite -x 0x1400001 -a 0x40000001 -P new -f list.pol

My grub settings are:

insmod multiboot2
insmod part_gpt
insmod ext2
set root='hd0,gpt2'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt2 --hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2  57da2c3c-2c6d-49e1-ac1a-e36155bbe884
else
  search --no-floppy --fs-uuid --set=root 57da2c3c-2c6d-49e1-ac1a-e36155bbe884
fi
echo    'Loading tboot 1.9.8 ...'
multiboot2    /boot/tboot.gz logging=serial,memory extpol=sha256
echo    'Loading Linux 4.15.0-39-generic ...'
module2 /boot/vmlinuz-4.15.0-39-generic root=UUID=57da2c3c-2c6d-49e1-ac1a-e36155bbe884 ro quiet intel_iommu=tboot_noforce noefi
echo    'Loading initial ramdisk ...'
module2 /boot/initrd.img-4.15.0-39-generic
echo    'Loading sinit 5th_gen_i5_i7_SINIT_79.BIN ...'
module2 /boot/5th_gen_i5_i7_SINIT_79.BIN
module2 /boot/list.data

(sudo update-grub doesn't add the list.data, so I added manually - not sure if this is the expected way.
Also I had to use tboot_noforce for the iommu setting since setting it to 'on' caused the system to behave very slow and inconsistently.)

The txt-stat logs indicate the following:

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:     rayees:01400001
TBOOT:     :70 bytes read
TBOOT: in unwrap_lcp_policy
TBOOT: rayees: in LCP_POLICY_DATA_FILE_SIGNATURE match
TBOOT: rayees: poldata->num_lists: 1
TBOOT: rayees: [0] pollist->version: 00000200
TBOOT: rayees: in LCP_TPM20_POLICY_LIST_VERSION
TBOOT:     :reading failed
TBOOT: failed to read policy from TPM NV, using default

(Entire logs are here: https://pastebin.com/R0SCz0Uc<https://urldefense.proofpoint.com/v2/url?u=https-3A__pastebin.com_R0SCz0Uc&d=DwMFaQ&c=zU8zY2zCUszYt_I-pOyd_mv7l16V_LqUcVo_CQ1Hrvg&r=xCzFiavp4AvlZMRboFbhUNHIE4_VgtudgLzlNKIi7-s&m=jJMcNogToGaC_s3NY9mcCB9MATAcjE5fK19feM1bhos&s=yXbdTFepowUqZjiVpTAwyrvZ1wTA6gKtXQpnjU3jLNs&e=>)

By looking at the code, it expects to read the verified launch policy from 0x1200001 and then
from the location 0x1400001, it expects to read only a custom element. If it is anything other
than a custom element, the read fails and it uses the default policy. I tried the address 0x1C10106,
which was also mentioned in some posts - but that didnt work either.

If I build a modified version of tboot and then copy it to the boot directory and use the same policy, the boot fails.
This would indicate that my policy is being used.


Policy files are attached, output from the show option is below:
 << File: list.pol >>  << File: list.data >>

$ lcp2_crtpol --show list.pol list.data
policy file: list.pol
     version: 0x300
     hash_alg: sha256
     policy_type: list
     sinit_min_version: 0x0
     data_revocation_counters: 0, 0, 0, 0, 0, 0, 0, 0,
     policy_control: 0x0
     max_sinit_min_ver: 0x0
     max_biosac_min_ver: 0x0
     lcp_hash_alg_mask: 0x8
     lcp_sign_alg_mask: 0x8
     aux_hash_alg_mask: 0x8
     policy_hash: 01 44 2e f1 27 b3 4e a0 7b 86 8c e2 65 0c 9b 41 1a 0d bf aa
9c d0 22 87 48 36 3e 3a db ea 4a 9d

policy data file: list.data
     file_signature: Intel(R) TXT LCP_POLICY_DATA
     num_lists: 1
     list 0:
         version: 0x200
         sig_alg: rsa
         policy_elements_size: 0x32 (50)
         policy_element[0]:
             size: 0x32 (50)
             type: 'mle' (16)
             policy_elt_control: 0x00000000
             data:
                 sinit_min_version: 0x0
                 hash_alg: sha256
                 num_hashes: 1
                 hashes[0]: ef 8f 4e 0c d7 fe f6 56 18 11 55 4f 14 7b 8f 82 5a 6c 07 f8
e7 68 fd 71 aa c8 09 be af 7b 7f 1f
         signature:
             revocation_counter: 0x0 (0)
             pubkey_size: 0x100 (256)
             pubkey_value:
                8f ff 60 c6 0e a6 61 6a b1 4d cc c1 96 4f 6e 01 9a 1d 45 3d
                56 60 9a af fb e4 11 f5 88 ad 51 12 6b c1 e5 26 32 3c 86 3a
                5c 22 87 27 61 b1 22 0a d8 b6 ba 11 ae 79 5e af 37 b6 a1 dc
                22 14 30 27 17 f0 a6 1e a9 24 b6 90 49 5d 1e f1 82 fe d2 2f
                7a b2 93 8a 17 47 17 fb 4f 6f d0 19 bf 61 48 e4 a5 69 8f 9c
                50 a9 73 77 13 77 25 86 fe d7 b1 64 a9 59 97 b3 88 a1 d2 60
                22 08 ce 49 95 52 44 ed 93 94 13 13 7b 9d 3c 37 71 51 b0 26
                6f 68 b1 59 e6 71 0b fe 4d c4 04 e5 1f e5 19 b7 9b 09 ec 26
                ba c7 61 03 48 9d 96 ee 5b 49 e3 ba 5c 90 3b bc 92 c3 7c d8
                e6 a2 d0 2d 73 9e 30 c7 8a e3 bb e7 42 2b cd 75 c8 81 64 06
                08 c3 16 2e 4e e6 d9 86 cb 06 5a 72 c0 01 2a be 39 91 19 1a
                71 be 30 14 51 31 67 bf 93 c7 62 28 18 98 2c d8 6f 56 f2 49
                9d 95 f3 6c b5 2d bb 76 93 09 ec 30 a4 25 ff a9
             sig_block:
                e0 c9 97 30 6e ed 37 62 62 ab 9a 53 a0 e8 5b af 1a 89 5f 65
                2a 43 7d 05 bf 5c 79 9c 37 3e 02 bf b5 ff 4f 36 2d e2 cc 7b
                e1 dc 5a 65 1a 24 9a 5d f8 25 b4 61 af 68 e2 97 09 a7 86 ee
                d9 f0 7e 86 1f 9b 41 4f f6 52 34 c9 34 da 6d a2 e7 05 96 50
                74 42 6b 1e b3 2a b7 b1 d4 5a 5c 52 99 06 f9 4d 77 87 23 c3
                00 a5 6a 58 cd be 2f 8d 33 c8 3c d7 09 eb 36 0d 7e e5 8b b5
                26 f2 3e 09 48 b0 c3 21 b7 9f 8b 33 d1 fd ba 7d 0f 1c 2a b5
                5d db de 2f b6 6f fe a3 e2 4c 36 39 b8 30 9f 09 bb 8a 1c 7b
                dd 72 1f 00 1d 45 39 65 80 66 e3 b7 b4 bb b7 57 10 8c 48 7e
                c8 0a 63 38 9a 32 ef 6f 15 f2 70 b1 f6 f3 80 1f 74 c9 a9 e6
                68 e9 37 9f 83 b1 03 14 5e 4b 33 df 4f 19 0d 37 45 83 d9 f7
                85 72 d7 2f d2 63 b8 a6 6e 07 f1 4e 3f 4f c0 89 43 c3 8d 38
                ed 15 13 3f 90 38 59 44 a2 e3 f8 09 9a 30 14 20
         signature verifies
01 44 2e f1 27 b3 4e a0 7b 86 8c e2 65 0c 9b 41 1a 0d bf aa
9c d0 22 87 48 36 3e 3a db ea 4a 9d

policy data hash matches policy hash

I would appreciate help from the tboot devs to understand tboot better and get it to work with LCP and VLP on TPM 2.0.

Also, I haven't been able to get the serial debug output with NUC after attaching the cable: https://www.microsatacables.com/serial-db9-to-2-0mm-10-pin-header-cable-672
If someone has any experience working with the Intel NUC and were able to get serial output, I would appreciate the help.

Thanks a lot
Rayees Shamsuddin

Re: [tboot-devel] tpm-tools: corrupt output of tpm_version command

[Matthias G. <mge...@su...>]

Sorry, this message went up the wrong mailing list. It was destined for
trousers tpm 1.2 tpm-tools. Please excuse the noise.

-- 
Matthias Gerstner <mat...@su...>
Dipl.-Wirtsch.-Inf. (FH), Security Engineer
https://www.suse.com/security
Telefon: +49 911 740 53 290
GPG Key ID: 0x14C405C971923553

SUSE Linux GmbH
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nuernberg)
On Fri, Nov 30, 2018 at 01:55:10PM +0100, Matthias Gerstner wrote:
> Hello,
> 
> a customer reported getting corrupt output when running the
> 'tpm_version' command. It turns out there are two issues in the code:
> 
> - NULL bytes in the TPM Vendor ID are output
> - Possibly undefined data is printed on stderr, since an unterminated
>   string buffer is used. This might also lead to a crash in some
>   circumstances
> 
> Please find attached two patches that address these two issues.
> 
> Regards
> 
> Matthias
> 
> -- 
> Matthias Gerstner <mat...@su...>
> Dipl.-Wirtsch.-Inf. (FH), Security Engineer
> https://www.suse.com/security
> Telefon: +49 911 740 53 290
> GPG Key ID: 0x14C405C971923553
> 
> SUSE Linux GmbH
> GF: Felix Imendörffer, Jane Smithard, Graham Norton
> HRB 21284 (AG Nuernberg)

> From c927f67f36a4719bd15b8a535efb6980f1e87a6b Mon Sep 17 00:00:00 2001
> From: Matthias Gerstner <mat...@su...>
> Date: Fri, 30 Nov 2018 12:48:37 +0100
> Subject: [PATCH] tpm_version: avoid outputting NULL bytes from tpmVendorID
> 
> When the vendor ID contains null bytes then '^@' characters appear in
> the tpm_version output. This can confuse users and it also causes e.g.
> 'grep' to treat the input as binary. Example:
> 
>   TPM Vendor ID:       WEC\000
> 
> This change copies the vendor ID bytes over into a local string object.
> This makes the code more independent of the vendor ID dimension and also
> avoids NULL bytes being printed.
> ---
>  src/tpm_mgmt/tpm_version.c | 9 ++++++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/src/tpm_mgmt/tpm_version.c b/src/tpm_mgmt/tpm_version.c
> index 1019b71..78b78e8 100644
> --- a/src/tpm_mgmt/tpm_version.c
> +++ b/src/tpm_mgmt/tpm_version.c
> @@ -133,6 +133,7 @@ int cmdVersion(const char *a_szCmd)
>  		UINT64 offset;
>  		TSS_RESULT uiResult;
>  		TPM_CAP_VERSION_INFO versionInfo;
> +		char vendor_id[sizeof(versionInfo.tpmVendorID)+1];
>  		char *errbuf = NULL; // Buffer containing what was sent to stderr during getCapability.
>  
>  		/* Disable logging to of "Bad Mode" during this call. 
> @@ -169,15 +170,17 @@ int cmdVersion(const char *a_szCmd)
>  			goto out_close;
>  		}
>  
> +		// copy over the individual characters into a regular string.
> +		// This avoids that null bytes are written to stdout.
> +		snprintf ( vendor_id, sizeof(vendor_id), "%s", (const char*)versionInfo.tpmVendorID );
> +
>  		logMsg(_("  TPM 1.2 Version Info:\n"));
>  		logMsg(_("  Chip Version:        %hhu.%hhu.%hhu.%hhu\n"),
>  		       versionInfo.version.major, versionInfo.version.minor,
>  		       versionInfo.version.revMajor, versionInfo.version.revMinor);
>  		logMsg(_("  Spec Level:          %hu\n"), versionInfo.specLevel);
>  		logMsg(_("  Errata Revision:     %hhu\n"), versionInfo.errataRev);
> -		logMsg(_("  TPM Vendor ID:       %c%c%c%c\n"),
> -		       versionInfo.tpmVendorID[0], versionInfo.tpmVendorID[1],
> -		       versionInfo.tpmVendorID[2], versionInfo.tpmVendorID[3]);
> +		logMsg(_("  TPM Vendor ID:       %s\n"), vendor_id);
>  
>  		if (versionInfo.vendorSpecificSize) {
>  			logMsg(_("  Vendor Specific data: "));
> -- 
> 2.18.1
> 

> From f0f30ff3e3b08751ebb8524303d80b6e94882134 Mon Sep 17 00:00:00 2001
> From: Matthias Gerstner <mat...@su...>
> Date: Fri, 30 Nov 2018 13:17:01 +0100
> Subject: [PATCH] tpm_version: avoid outputting undefined data on stderr
> 
> If there was no data written to the temporary file then memsize == 1, no
> data will be read from the file into the buffer and the buffer will not
> be null terminated. This can cause random data to be output later on to
> the original stderr like:
> 
> '#precedence ::ffff:0:0/'
> 
> or
> 
> 'xl?8?'
> 
> Fix this by making sure the buffer is always zero terminated.
> ---
>  src/tpm_mgmt/tpm_version.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/src/tpm_mgmt/tpm_version.c b/src/tpm_mgmt/tpm_version.c
> index 78b78e8..e563a8c 100644
> --- a/src/tpm_mgmt/tpm_version.c
> +++ b/src/tpm_mgmt/tpm_version.c
> @@ -99,6 +99,9 @@ char* end_capture_stderr(int olderr)
>      perror("read()");
>    }
>  
> +  // make sure the buffer is null terminated.
> +  buf[st.st_size] = '\0';
> +
>    // Restore stderr.
>   errout:
>    if (0 > dup2(olderr, STDERR_FILENO)) {
> -- 
> 2.18.1
> 





> _______________________________________________
> tboot-devel mailing list
> tbo...@li...
> https://lists.sourceforge.net/lists/listinfo/tboot-devel

[tboot-devel] tpm-tools: corrupt output of tpm_version command

[Matthias G. <mge...@su...>]

Hello,

a customer reported getting corrupt output when running the
'tpm_version' command. It turns out there are two issues in the code:

- NULL bytes in the TPM Vendor ID are output
- Possibly undefined data is printed on stderr, since an unterminated
  string buffer is used. This might also lead to a crash in some
  circumstances

Please find attached two patches that address these two issues.

Regards

Matthias

-- 
Matthias Gerstner <mat...@su...>
Dipl.-Wirtsch.-Inf. (FH), Security Engineer
https://www.suse.com/security
Telefon: +49 911 740 53 290
GPG Key ID: 0x14C405C971923553

SUSE Linux GmbH
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nuernberg)

[tboot-devel] TIMEOUT_C in tboot/include/tpm.h

[王强 <wan...@gm...>]

Hello tboot devs

TIMEOUT_C is used for TPM_DATA_AVAIL_TIME_OUT in  function tpm_submit_cmd.

It's defined in tboot/include/tpm.h , value  is  75000, and  comments as
750ms.
However, TIMEOUT_A and TIMEOUT_D are defined in the same file, their
comments are 750ms ，but  their value are 750, not 75000.

Why TIMEOUT_C is 75000, should it  be  750 as other timeout comments as
750ms?

[tboot-devel] tboot 1.9.9 released

[Wei, G. <gan...@in...>]

This minor release is to provide hotfixes for some potential issues found in 1.9.8.

Source package tboot-1.9.9.tar.gz & tboot-1.9.9.tar.gz.gpg can be downloaded from sourceforge.net.

Major changes since 1.9.8 (20181018)
        tools: fix some dereference-NULL issues reported by klocwork
        tools: replace banned mem/str fns with corresponding ones in safestringlib
        Add safestringlib code to support replacement of banned mem/str fns
        lcptools: remove tools supporting platforms before 2008
        tboot: update string/memory fn name to differentiate from c lib
        Fix a harmless overflow caused by wrong loop limits

Please help to try it, test it, and enjoy it.

Thanks
Jimmy

[tboot-devel] Tboot on TPM2.0 (Intel NUC5i5MYHE) on Ubuntu 16.04 LTS

[Rayees S. <Ray...@in...>]

Hi tboot devs,

I am trying to get tboot to work with TPM2.0 on an Intel NUC5i5MYHE on Ubuntu 16.04. I am able to boot with tboot using the default policy. However when I try to define my own policy, it fails to read the policy from the NV and uses the default policy. I have looked up the different posts on this list, but couldn't figure out the process exactly. I would appreciate any help to understand tboot and get it working. My end goal is to be replicate a policy for TPM2.0 similar to one suggested in https://wiki.gentoo.org/wiki/Trusted_Boot

These are the commands I used:
tpm2_takeownership -o new -e new -l new
tpm2_nvdefine -x 0x1400001 -a 0x40000001 -s 70 -t 0x004000A -P new (attribute of 0x204000A gave error 'Invalid PO Attr')
lcp2_mlehash --create --alg sha256 --cmdline "logging=serial,memory extpol=sha256" /boot/tboot.gz > tboot_hash
lcp2_crtpolelt --create --type mle --alg sha256 --ctrl 0x00 --minver 0 --out tbootmle.elt tboot_hash
lcp2_crtpollist --create --out list_unsig.lst tbootmle.elt
cp list_unsig.lst list_sig.lst
openssl genrsa -out privkey.pem 2048
openssl rsa -pubout -in privkey.pem -out pubkey.pem
lcp2_crtpollist --sign 0x8 --sigalg rsa --pub pubkey.pem --priv privkey.pem --out list_sig.lst
lcp2_crtpol --create --type list --pol list.pol --alg sha256 --sign 0x8 --data list.data list_sig.lst
sudo cp list.data /boot
tpm2_nvwrite -x 0x1400001 -a 0x40000001 -P new -f list.pol

My grub settings are:

insmod multiboot2
insmod part_gpt
insmod ext2
set root='hd0,gpt2'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt2 --hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2  57da2c3c-2c6d-49e1-ac1a-e36155bbe884
else
  search --no-floppy --fs-uuid --set=root 57da2c3c-2c6d-49e1-ac1a-e36155bbe884
fi
echo    'Loading tboot 1.9.8 ...'
multiboot2    /boot/tboot.gz logging=serial,memory extpol=sha256
echo    'Loading Linux 4.15.0-39-generic ...'
module2 /boot/vmlinuz-4.15.0-39-generic root=UUID=57da2c3c-2c6d-49e1-ac1a-e36155bbe884 ro quiet intel_iommu=tboot_noforce noefi
echo    'Loading initial ramdisk ...'
module2 /boot/initrd.img-4.15.0-39-generic
echo    'Loading sinit 5th_gen_i5_i7_SINIT_79.BIN ...'
module2 /boot/5th_gen_i5_i7_SINIT_79.BIN
module2 /boot/list.data

(sudo update-grub doesn't add the list.data, so I added manually - not sure if this is the expected way.
Also I had to use tboot_noforce for the iommu setting since setting it to 'on' caused the system to behave very slow and inconsistently.)

The txt-stat logs indicate the following:

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:     rayees:01400001
TBOOT:     :70 bytes read
TBOOT: in unwrap_lcp_policy
TBOOT: rayees: in LCP_POLICY_DATA_FILE_SIGNATURE match
TBOOT: rayees: poldata->num_lists: 1
TBOOT: rayees: [0] pollist->version: 00000200
TBOOT: rayees: in LCP_TPM20_POLICY_LIST_VERSION
TBOOT:     :reading failed
TBOOT: failed to read policy from TPM NV, using default

(Entire logs are here: https://pastebin.com/R0SCz0Uc<https://urldefense.proofpoint.com/v2/url?u=https-3A__pastebin.com_R0SCz0Uc&d=DwMFaQ&c=zU8zY2zCUszYt_I-pOyd_mv7l16V_LqUcVo_CQ1Hrvg&r=xCzFiavp4AvlZMRboFbhUNHIE4_VgtudgLzlNKIi7-s&m=jJMcNogToGaC_s3NY9mcCB9MATAcjE5fK19feM1bhos&s=yXbdTFepowUqZjiVpTAwyrvZ1wTA6gKtXQpnjU3jLNs&e=>)

By looking at the code, it expects to read the verified launch policy from 0x1200001 and then
from the location 0x1400001, it expects to read only a custom element. If it is anything other
than a custom element, the read fails and it uses the default policy. I tried the address 0x1C10106,
which was also mentioned in some posts - but that didnt work either.

If I build a modified version of tboot and then copy it to the boot directory and use the same policy, the boot fails.
This would indicate that my policy is being used.


Policy files are attached, output from the show option is below:


$ lcp2_crtpol --show list.pol list.data
policy file: list.pol
     version: 0x300
     hash_alg: sha256
     policy_type: list
     sinit_min_version: 0x0
     data_revocation_counters: 0, 0, 0, 0, 0, 0, 0, 0,
     policy_control: 0x0
     max_sinit_min_ver: 0x0
     max_biosac_min_ver: 0x0
     lcp_hash_alg_mask: 0x8
     lcp_sign_alg_mask: 0x8
     aux_hash_alg_mask: 0x8
     policy_hash: 01 44 2e f1 27 b3 4e a0 7b 86 8c e2 65 0c 9b 41 1a 0d bf aa
9c d0 22 87 48 36 3e 3a db ea 4a 9d

policy data file: list.data
     file_signature: Intel(R) TXT LCP_POLICY_DATA
     num_lists: 1
     list 0:
         version: 0x200
         sig_alg: rsa
         policy_elements_size: 0x32 (50)
         policy_element[0]:
             size: 0x32 (50)
             type: 'mle' (16)
             policy_elt_control: 0x00000000
             data:
                 sinit_min_version: 0x0
                 hash_alg: sha256
                 num_hashes: 1
                 hashes[0]: ef 8f 4e 0c d7 fe f6 56 18 11 55 4f 14 7b 8f 82 5a 6c 07 f8
e7 68 fd 71 aa c8 09 be af 7b 7f 1f
         signature:
             revocation_counter: 0x0 (0)
             pubkey_size: 0x100 (256)
             pubkey_value:
                8f ff 60 c6 0e a6 61 6a b1 4d cc c1 96 4f 6e 01 9a 1d 45 3d
                56 60 9a af fb e4 11 f5 88 ad 51 12 6b c1 e5 26 32 3c 86 3a
                5c 22 87 27 61 b1 22 0a d8 b6 ba 11 ae 79 5e af 37 b6 a1 dc
                22 14 30 27 17 f0 a6 1e a9 24 b6 90 49 5d 1e f1 82 fe d2 2f
                7a b2 93 8a 17 47 17 fb 4f 6f d0 19 bf 61 48 e4 a5 69 8f 9c
                50 a9 73 77 13 77 25 86 fe d7 b1 64 a9 59 97 b3 88 a1 d2 60
                22 08 ce 49 95 52 44 ed 93 94 13 13 7b 9d 3c 37 71 51 b0 26
                6f 68 b1 59 e6 71 0b fe 4d c4 04 e5 1f e5 19 b7 9b 09 ec 26
                ba c7 61 03 48 9d 96 ee 5b 49 e3 ba 5c 90 3b bc 92 c3 7c d8
                e6 a2 d0 2d 73 9e 30 c7 8a e3 bb e7 42 2b cd 75 c8 81 64 06
                08 c3 16 2e 4e e6 d9 86 cb 06 5a 72 c0 01 2a be 39 91 19 1a
                71 be 30 14 51 31 67 bf 93 c7 62 28 18 98 2c d8 6f 56 f2 49
                9d 95 f3 6c b5 2d bb 76 93 09 ec 30 a4 25 ff a9
             sig_block:
                e0 c9 97 30 6e ed 37 62 62 ab 9a 53 a0 e8 5b af 1a 89 5f 65
                2a 43 7d 05 bf 5c 79 9c 37 3e 02 bf b5 ff 4f 36 2d e2 cc 7b
                e1 dc 5a 65 1a 24 9a 5d f8 25 b4 61 af 68 e2 97 09 a7 86 ee
                d9 f0 7e 86 1f 9b 41 4f f6 52 34 c9 34 da 6d a2 e7 05 96 50
                74 42 6b 1e b3 2a b7 b1 d4 5a 5c 52 99 06 f9 4d 77 87 23 c3
                00 a5 6a 58 cd be 2f 8d 33 c8 3c d7 09 eb 36 0d 7e e5 8b b5
                26 f2 3e 09 48 b0 c3 21 b7 9f 8b 33 d1 fd ba 7d 0f 1c 2a b5
                5d db de 2f b6 6f fe a3 e2 4c 36 39 b8 30 9f 09 bb 8a 1c 7b
                dd 72 1f 00 1d 45 39 65 80 66 e3 b7 b4 bb b7 57 10 8c 48 7e
                c8 0a 63 38 9a 32 ef 6f 15 f2 70 b1 f6 f3 80 1f 74 c9 a9 e6
                68 e9 37 9f 83 b1 03 14 5e 4b 33 df 4f 19 0d 37 45 83 d9 f7
                85 72 d7 2f d2 63 b8 a6 6e 07 f1 4e 3f 4f c0 89 43 c3 8d 38
                ed 15 13 3f 90 38 59 44 a2 e3 f8 09 9a 30 14 20
         signature verifies
01 44 2e f1 27 b3 4e a0 7b 86 8c e2 65 0c 9b 41 1a 0d bf aa
9c d0 22 87 48 36 3e 3a db ea 4a 9d

policy data hash matches policy hash

I would appreciate help from the tboot devs to understand tboot better and get it to work with LCP and VLP on TPM 2.0.

Also, I haven't been able to get the serial debug output with NUC after attaching the cable: https://www.microsatacables.com/serial-db9-to-2-0mm-10-pin-header-cable-672
If someone has any experience working with the Intel NUC and were able to get serial output, I would appreciate the help.

Thanks a lot
Rayees Shamsuddin

[tboot-devel] TXT measured launch: TRUE + ERR: CPU does not support SMX

[De O. H. G. <hor...@in...>]

Hi! I successfully configured tboot with Fedora 28 and
it is booting my system, I have hashes in PCR0-PCR9,
and 0xff on PCR17-PCR22.

Since PCR17-PCR22 have all 0xff I understand my attempt
to have tboot working failed, but in the output of txt-stat I found:

* TXT measured launch: TRUE
* ERRORCODE: 0x00000000

In the other hand, I also found:

* TBOOT: ERR: CPU does not support SMX

So, I don't know how to read that... Since CPU does not supports
SMX, can I say it will never work? (the CPU indeed does not have smx
support, it does not appears in /proc/cpuinfo).

I want to know if I should keep trying, or just looking for new hardware
(I'm using a NUC7i7BNH)

Thanks in advance,
Horacio

Re: [tboot-devel] tpmnv_defindex

[Wei, G. <gan...@in...>]

Tpmnv_defindex does not support well-known password.

Thanks
Jimmy

From: Jeanne Greulich [mailto:jea...@on...] 
Sent: Tuesday, September 11, 2018 1:10 AM
To: tbo...@li...
Subject: [tboot-devel] tpmnv_defindex

Hello,

I am using tboot 1.9.7.  I am tryng to create a vlp.

When I run tpmnv_defindex it does not work if I have the owner password set to the well-know password.  I have tried  -y and -p '00000000000000000000'

It works fine when I have the password something other than the well know password.

Is this expected behavior?

Thank you for your time,

Jeanne Greulich

[tboot-devel] tboot 1.9.8 released

[Wei, G. <gan...@in...>]

This minor release is to provide hotfixes for S3 issues found in 1.9.7.



Source package tboot-1.9.8.tar.gz & tboot-1.9.8.tar.gz.gpg can be downloaded from sourceforge.net.



Major changes since 1.9.7 (20180830):

        Skip tboot launch error index read/write when ignore prev err option is true

        s3-fix: fix a stack overflow caused by enlarged tb_hash_t union

        S3 fix: revert the mis-changed type casting in changeset 522:8e881a07c059

        S3-fix: Adding option save_vtd=true to opt-in the vtd table restore



Please help to try it, test it, and enjoy it.



Thanks

Jimmy

[tboot-devel] tpmnv_defindex

[Jeanne G. <jea...@on...>]

Hello,

I am using tboot 1.9.7.  I am tryng to create a vlp.

When I run tpmnv_defindex it does not work if I have the owner password set
to the well-know password.  I have tried  -y and -p '00000000000000000000'

It works fine when I have the password something other than the well know
password.

Is this expected behavior?

Thank you for your time,

Jeanne Greulich

Re: [tboot-devel] Platform Security Summit 2018

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

> On May 1, 2018, at 20:33, Rich Persaud <pe...@gm...> wrote:
> 
> PSEC 2018 brings together security researchers and developers from the open-source ecosystems of OpenEmbedded, Xen Project and OpenXT, including presentations on measured launch, UEFI and TPM 2.0.
> 
> With a focus on hardware-based security and commercially extensible open source, this 2-day, single track event is for hardware and firmware engineers, VMM and OS developers, security architects, integrators and senior technical staff.  

Boot integrity talks from Bromium, Dell, Intel, Oracle and others have been posted:
https://www.platformsecuritysummit.com/2018/topic/boot/

Rich

[tboot-devel] tboot 1.9.7 released

[Wei, G. <gan...@in...>]

This minor release is to provide mitigations for a series of reported vulnerabilities and issues.

Source package tboot-1.9.7.tar.gz & tboot-1.9.7.tar.gz.gpg can be downloaded from sourceforge.net.

Major changes since 1.9.6 (20170711):
        Fix a lot of issues reported by klocwork scan.
        Fix 4 issues along with extpol=agile option
        Mitigations for tpm interposer attacks
        Add an option in tboot to force SINIT to use the legacy TPM2 log format.
        Add support for appending to a TPM2 TCG style event log.
        Ensure tboot log is available even when measured launch is skipped.
        Add centos7 instructions for Use in EFI boot mode.
        Fix memory leak and invalid reads and writes issues.
        Fix TPM 1.2 locality selection issue.
        Fix a null pointer dereference bug when Intel TXT is disabled.
        Optimize tboot docs installation.
        Fix security vulnerabilities rooted in tpm_if structure and g_tpm variable.
        Fix openssl-1.0.2 double frees
        Make policy element stm_elt use unique type name
        lcptools-v2 utilities fixes
        port to openssl-1.1.0
        Reset debug PCR16 to zero.
        Fix a logical error in function bool evtlog_append(...).

Please help to try it, test it, and enjoy it.

Thanks
Jimmy

Re: [tboot-devel] lcp_crtpollist crashing

[Matthias G. <mge...@su...>]

Hello,

On Wed, Aug 29, 2018 at 07:05:48PM -0400, Jeanne Greulich wrote:
> I am using tboot.1.9.6 on CentOS 7.5 with TPM 1.2.  Using the following to
> create the policy:
[...]
> but this always crashes with
> *** Error in `lcp_crtpollist': double free or corruption (out):
> 0x0000000001d387f0 ***
> Segmentation fault
> 
> Is this a known problem?

there have been fixes in this area in commits [1] and [2]. It looks like
there is no release available yet that contains these fixes. So building
a development version might help, or adding the patches to the CentOS
packaging of tboot. I did the latter for the openSUSE Linux tboot
package that I am maintaining.

Cheers

Matthias

[1]: https://sourceforge.net/p/tboot/code/ci/09fae64a7515d240b2822cf0d08e1f36e8130983
[2]: https://sourceforge.net/p/tboot/code/ci/d4452e9380b863581e02edd139b44dc565cde03d

-- 
Matthias Gerstner <mat...@su...>
Dipl.-Wirtsch.-Inf. (FH), Security Engineer
https://www.suse.com/security
Telefon: +49 911 740 53 290
GPG Key ID: 0x14C405C971923553

SUSE Linux GmbH
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nuernberg)

[tboot-devel] lcp_crtpollist crashing

[Jeanne G. <jea...@on...>]

I am using tboot.1.9.6 on CentOS 7.5 with TPM 1.2.  Using the following to
create the policy:

lcp_mlehash -c "${GRUB_CMDLINE_TBOOT}" /boot/tboot.gz > mle_hash


lcp_crtpolelt --create --type mle --ctrl 0x00 --minver 17 --out mle.elt
mle_hash


cat `find /sys/devices -name pcrs` | grep -e PCR-0[01] > pcrs
lcp_crtpolelt --create --type pconf --out pconf.elt pcrs


lcp_crtpollist --create --out list_unsig.lst mle.elt pconf.elt


openssl genrsa -out privkey.pem 2048 &> /dev/null
openssl rsa -pubout -in privkey.pem -out pubkey.pem &> /dev/null
cp list_unsig.lst list_sig.lst
lcp_crtpollist --sign --pub pubkey.pem --priv privkey.pem --out list_sig.lst

but this always crashes with
*** Error in `lcp_crtpollist': double free or corruption (out):
0x0000000001d387f0 ***
Segmentation fault

Is this a known problem?


Jean Greu

Re: [tboot-devel] Fwd: TXT/TPM 2.0 and tboot Launch control policy

[Sant Y <sat...@gm...>]

>
> According to the latest spec (https://www.intel.com/content/www/us/en/software-developers/intel-txt-software-development-guide.html) from Intel (and at least since version 013 from August 2016), you have to use 0x01C10106 for LCP Platform Owner. See Appendix J, the statement beginning with "TXT ACMs will support only 0x1C1_xxxx index set."
>
> You should be able to provision that index with tpm2_tools' tpm2_nvdefine command.

That was indeed a problem. After changing the index it works. Thank you Travis!
I still get the 'reading failed' errors in Tboot logs. But from my
tests, the MLE works fine, and the boot halts if there are changes
detected. So I wouldn't bother about the error messages now.

Also, are the "tb_polgen" generated policies still valid? I was
attempting a verified launch (mostly following the guidelines here :
https://wiki.gentoo.org/wiki/Trusted_Boot#Setting_the_Launch_Control_Policy
and using lcp2_* tools instead of lcp).
The VLP doesn't seem to have any effect.
tb_polgen "--show" can't be used with new policy files, hence the
question. Is there a way to generate VLP with lcp2_* tools ?