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: g...@enjellic.com
------------------------------------------------------------------------------
"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
_______________________________________________
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel
