Re: [tboot-devel] TPM 2.0 + TXT + EFI tboot

[Dr. Greg Wettstein]

On Dec 8,  5:04pm, Brian E Luckau wrote:
} Subject: Re: [tboot-devel] TPM 2.0 + TXT + EFI tboot

Hi Brian, good morning to the list as well.

> On 12/08/2016 05:00 PM, Sun, Ning wrote:
> >
> > In grub.cfg, find the line=multiboot2  /boot/tboot.gz
> > logging=serial,memory,  add extpol=sha256 at end of the line.

> Is that likely to also help an issue I am having where it reboots
> after getsec[SENTER] every time I have EFI enabled? We are on a BIOS
> that has the AC Init module built into the BIOS.

As I indicated in my response to Travis, that may help, but it is
currently not addressing similar issues we are seeing in more advanced
measured launch configurations on TPM2/TXT systems.

I'm assuming, based on your comment above, that you are able to
demonstrate a basic MLE with legacy boot enabled?  We have that rock
solid on our development platforms.  As I noted in my previous e-mail,
EFI is its own can of worms.

We are currently blocked, in our development efforts, with trying to
get a successful MLE boot with any type of Platform Owner Launch
Control Policy PO/LCP defined.  Hence my question to Travis, and to
you, as to whether or not you have PO NVram index locations defined on
your development machines.  If not I suspect you have an EFI related
problem which is probably going to require involvement from whoever is
doing the BIOS/firmware for these systems.

The LCPv2 tool in the tboot package (lcp2_crtpol), according to our
read of the Intel TXT Software Development Manual, is not capable of
generating valid Launch Control Policies for TPM2 based systems.  The
tools do have command-line options which make it look like they can
take algorithm agility into account but the generated policy appears
to be invalid.  We have patched the tools to generate what we believe
is a valid PO ANY policy but we are still seeing immediate resets
after GETSEC[SENTER] invocation of the ACM, when any type of policy is
loaded into the PO NVram index.

After the system reset the TXT.ERRCODE hardware register is zeroed out
so there is no indication as to what the ACM is running into.

Again, with legacy boot, we are able to get a successful launch with
only the Platform Supplier (PS) index present.  That index should be
provisioned by the Intel EFI based TXT provisioning utilities which I
assume that both you and Travis used to provision the TPM2 hardware on
your development systems.

We need to implement PCONF, or on TPM2 based systems PCONF2 based
launch control policies, but we currently cannot get systems to boot
when the most basic ANY policy is loaded.

Just as an aside, the PCONF based policies on TPM1.2 based systems are
based on the simple model of an extension measurement over a set of
PCR registers.  The PCONF2 based policy depends on the generation and
inclusion of a tpms_quote (PCR quotation) value out of the TPM2 for a
given set of registers.  I'm not sure that this even exists outside of
a description in the documentation, we would be really interested in
knowing if anyone has even attempted to get this working.

On that note.

The e-mail address which this is coming from is my 20+ year INTERNET
address which is from the company which owns the company that I do
TPM/TXT/SGX hardware security engineering for.  I'm pretty confident
that I could get that company to spring for a conference call to get
engineers from companies who are interested in getting these
TPM2/TBOOT issues resolved together to coordinate getting a handle on
some of these issues.

As it stands now I think we have a lot of frustrated people working on
an inherently undebuggable platform.  This is limiting everyone's
productivity with respect to creating whatever security systems are
the ultimate objects of this work on basic infrastructure.

Anyone interested can reply to me privately if they want to take if
off list.  Put tboot somewhere in the subject so my mail filters will
pick it out.  I get 10,000+ e-mails a week to this account... :-)

Have a good weekend.

Greg

}-- End of excerpt from Brian E Luckau

As always,
Dr. G.W. Wettstein, Ph.D.   Enjellic Systems Development, LLC.
4206 N. 19th Ave.   Specializing in information infra-structure
Fargo, ND  58102development.
PH: 701-281-1686
FAX: 701-281-3949   EMAIL: g...@enjellic.com
--
"OK, f***ing mess with us.  We're taking our fibre-channel switch and
 we're going home."
-- SAN administrator
   Resurrection

-- 

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
___
tboot-devel mailing list

Re: [tboot-devel] TPM 2.0 + TXT + EFI tboot

[Dr. Greg Wettstein]

On Dec 8, 10:22pm,  wrote:
} Subject: [tboot-devel] TPM 2.0 + TXT + EFI tboot

Good morning, I hope this note finds the end of the week going well
for everyone.

> I am trying to perform a simple trusted boot on SLES 12 SP2 with TPM
> 2.0 and EFI mode. I can verify that TXT works using getsec64.efi and
> performing SENTER, setting the secrets flag, rebooting and doing
> SENTER then SEXIT. When I select the "tboot 1.9.4" entry in grub2, my
> server pauses for a bit after the loading initial RAM disk step and
> then reboots. I then get an SINIT error notification from BIOS that
> points to a log error (ERR_BAD_LOG_POINTER_PTR2_MATCH).
>
> I am working with a freshly provisioned TPM and a new install of
> SLES 12 SP2. I added the tboot and tpm2.0-tools packages to that
> install and modified grub2 to give me a tboot prompt (I think I added
> a file grub-tboot to /etc/default/ to accomplish this).
>
> Am I missing anything?

We've been working for almost 10 months, albeit intermittently,
attempting to get a TPM2/TXT environment operational for our security
platforms without complete success.  I see that Brian Luckau from SGI
commented downthread and it appears they are still struggling to get
something working as well.

So you folks at Dell are probably not missing anything as much as the
fact that we are not convinced that anyone has worked out all of the
issues with Trusted Boot on modern Intel hardware, ie. TPM2 based
systems.

If possible, could you provide some feedback on the hardware platform
you are working on.  I'm assuming it is a Dell box of some sort... :-)
I'm also assuming it is vPro compliant, with hardware TPM2 and that
you are able to successfully access the TPM2 hardware from a standard
Linux boot and read NVram, dump PCR's etc?

For your reference purposes, I see that you are attempting an EFI
based boot, have you tried to demonstrate a successful measured launch
environment (MLE) with legacy boot enabled?  We are currently able to
demonstrate a successful, but minimal, MLE with legacy boot on our
Broadwell NUC5i5MYBE development platforms.  We are currently avoiding
EFI due to complexity and firmware vagary issues.

I see that Ning Sun from Intel replied downthread as well and
recommended that you restrict algorithm agility to SHA256 with the
extpol=sha256 command-line directive to tboot.  We have been using
that for months in our minimal boot environment but that doesn't get
us past where we are currently blocked on more advanced MLE
configurations.

Secondly, do you have a Platform Owner Launch Control Policy PO/LCP
defined?  You can check this by seeing whether or not the NVram index
location 0x141 has been defined.  I'm assuming your hardware/ACM
environment is not so new that it would be using the newer 0x1c10106
index location.

The tpm2-tools package should have a utility for dumping out NVram
index locations.  We wrote our own TPM2 tooling from scratch based on
Ken Goldman's TSS2 reference library, which comes out of IBM's TJ
Watson labs and which is rock solid from a standards conformance
perspective.  I can send you a Linux statically linked diagnostic
binary if you have problems looking for the PO policy indexes.

Provided, of course, that you have basic userspace control of the TPM2
chip in hand.  I'm assuming your hardware is implementing a
TIS/MSFT0101 ACPI interface?  ACPI/CRB support seems to be a big dodgy
unless you are using custom rolled Linux kernels.

Hopefully the above information is helpful in moving your work
forward.  We would be interested in any feedback you might have on our
questions above.

Have a good day.

Greg

}-- End of excerpt from 

As always,
Dr. G.W. Wettstein, Ph.D.   Enjellic Systems Development, LLC.
4206 N. 19th Ave.   Specializing in information infra-structure
Fargo, ND  58102development.
PH: 701-281-1686
FAX: 701-281-3949   EMAIL: g...@enjellic.com
--
"If you get to thinkin' you're a person of some influence, try
 orderin' somebody else's dog around."
-- Cowboy Wisdom


-- 

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
___
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel