Tboot issues on Intel Server board E5-2658

Tboot issues on Intel Server board E5-2658

Hello guys

I have been trying to implement trusted boot feature in our server and testing it with the tools Intel provides (ServerTXTINFO, getsec64, and Serversecret).

But I am getting bunch of errors. txt-stat in my red hat terminal shows that secret and secret flag set = False but TXT Measured launch = True.

When I run getsec64.efi tool in EFI shell, I get error that System is already in TXT environment run getsec64 -l sexit

and when I run getsec64 -l sexit, I get GETSEC leaf or SMCTRL leaf unavailable.

I have searched everywhere in BIOS but couldn't find any related option.

I have generated platform log file using serverTXTinfo which is attached. It has errors about GETSEC capabilities showing that Intel TXT-capable chipset bit is 0 (Which I suppose, should be set) and heap memory is not allocated.

I can't really understand these error. Any help will be highly appreciated.

Implementation process:

TBOOT installation process is followed from

(https://software.intel.com/sites/default/files/managed/2f/7f/Config_Guid...)

BIOS configuration: TPM, Intel TXT (LT-Sx), VT-d and VMX are enabled.

OS: Red Hat Enterprise Linux 6.5

we have Intel Server board E5- 2658 with Mayan City Haswell EP based system with RC115 BIOS installed, it has QS Haswell CPU’s and B1 Wellsburg.

 

AttachmentSize
Downloadapplication/octet-stream myplaform1.log36.31 KB
Downloadimage/jpeg 1.jpg263.45 KB
13 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

You do need to get the secrets enabled. Take a look at http://downloadmirror.intel.com/18931/eng/Intel%20TXT%20LAB%20Handout.pdf

Best Reply

Looking at the TXTinfo log you attached, it appears there are a couple of main problems with your system:

  • As you noted, "TXT-capable chipset is present" is showing as false.  This generally means that the straps on the board are not set to enable TXT.  So, you should first check the hardware straps (TXT_PLTEN and TXT_AGENT) to ensure they are set to enable TXT.  Note, I have seen several Mayan City boards where the DIP switches to control these signals were inserted backwards.  In those boards, the proper settings to enable TXT are:

    • CPU0 (S3F1 dipswitch)  -switch 1: OFF,  -switch 2: ON

    • CPU1 (S8F1 dipswitch)  - switch 1: OFF,   -- switch 2:  OFF

  • The TPM doesn’t appear to be provisioned for TXT – the AUX and PS indexes are not present on the TPM.  So, you will need to run the ServerTPMTool.efi provisioning tool in order to provision the TPM for TXT support.  The BIOS is showing you have an NPW signed ACM, so you will need to generate a PS policy that allows NPW ACMs to run.   We provide a DefaultTPMProvisionNPW-Unlocked.nsh script in the release package for the provisioning tool that you can use to easily provision the TPM from the EFI shell.

I’m not sure why measured launch would be showing as TRUE, since clearly the system can’t be doing a measured launch in this case.  That is odd.  But the fact that the secrets bit is not set indicates that the system is not truly in a secure TXT MLE state.

Thanks JEFF for instant reply

Is there any way to check (with any tool) if these hardware straps are set without opening the server board?

I checked that I am missing ServerTPMtool.efi and unlock script in my TPM tool kit. are these available online somewhere?

 

 

 

 

@Colleen Culbertson

I have tried to enable the secret through ServerSecret.efi tool and got success message that secret bit is asserted but the problem still exists.

 

Update:

I checked in the board and dipswitches were not set. I set them as JEFF recommended and I see that chipset present bit is set to 1.

Then,  I ran getsec64 -L SENTER -a command in EFI shell  but got error that supplied file is not a SINIT AC module. I read that for E5-2658 board sinit file is embedded in BIOS. Shouldn't it pick sinit file from the BIOS or is there anything I am missing?

Regards,

Shankar

 

 

Shankar,

Good to hear that you got the hardware straps set, and the TXT enabled chipset present is now showing as true.

The SINIT ACM is indeed embedded in the BIOS, and the getsec64 tool will load it from BIOS.  You don't need to specify the -a option when running the getsec64 tool.  That's only if you want to specify an external ACM file for the tool to load.

You are still going to see a failure however until you get your TPM provisioned for TXT.  The BIOS ACM (startup ACM) will fail since the TPM is not provisioned, so the BIOS will never copy the SINIT ACM to the heap in order to do the trusted launch.

I assume you have an Intel IBL account since you have the ServerTXTInfo and the getsec tools.  The TPM provisioning tool is also available on IBL.  You'll need to go download it, and then run the script I mentioned in the previous post.  The document number on IBL for the TPM provisioning tool is #519613

Update:

I have got the TPM provisioning tools. I ran the script defaulttpmprovisionnpw-unlocked.nsh.

but now when I try to  test the secure launch capability using getsec64.efi tool, the system restarts. This happens every time when I run getsec tool. It does not seem like TXT reset. (attached is the platform log).
 

Can't figure out what is wrong now. Any help?

 

 

Attachments: 

AttachmentSize
Downloadapplication/octet-stream final.log34.61 KB

Shankar,

You're definitely making progress.  The TXTinfo log you attached shows that you now have the TPM provisioned and the BIOS ACM is successfully executing.  The log does however show that you are indeed getting a TXT reset.   A TXT Errorcode  of 0xC0091C61 is shown, which indicates that you got a TXT reset.  This error decodes to "PO policy integrity check failure".

From what I can tell, it looks like you've created a PO policy that does not allow NPW ACMs to run.  Your PS policy is allowing an NPW ACM to run, but the PO policy overrides the PS policy.  This is probably why you're failing.  From the log, I can't tell for sure, but I suspect you have an NPW ACM.  When you run the servertxtinfo tool next time, use the command line:  servertxtinfo -c:a -a -v:2 > outputfilename.log.   This will provide some extended information, including information on what version of ACM is being used.

If you're using an NPW ACM, to fix your problem you would need to either change your PO policy to allow an NPW ACM to run, or just remove your PO policy and let the default PS policy (which is allowing NPW ACMs to run) execute.

Jeff

 

Thanks Jeff for kind reply.
 

Actually I am not sure if I have created and setup any PO policy on our platform. I have only installed tboot and tpm tools in our newly installed Redhat 6.5 server and created LCP policy using default scripts available at:

https://raw.githubusercontent.com/yocum137/txt-oat/master/scripts/create...

Please also find attached extended platform log file for further insight.

Any idea how to edit or remove PO policy?

Thanks

Attachments: 

AttachmentSize
Downloadapplication/octet-stream serverlog1.log52.44 KB

Since you ran the scripts from the link you provided, you have indeed created a PO policy.  In fact, you've created a signed list LCP. 

Your expanded TXTinfo log file shows that you are running NPW signed ACMs.  Your PO LCP is only allowing PW ACMs to run - hence the error.  You could change your PO policy to allow NPW ACMs to run, but I suspect you would then fail the LCP signed list criteria - depending on which version of Tboot you're running.

For basic testing, the simplest thing to do is either have no PO policy, or have a PO policy that allows any MLE to run.  Since you've already created a PO policy, you would need to modify it to 1) allow NPW ACMs to run, and 2) allow ANY MLE to run.  To do this, you'll need to modify the scripts you're using.  This gets a little more complicated and would be hard to walk you through on this forum.  I'd point you to the TXT software development guide and related documents which have information on this.

Alternately, what I'd recommend is just to just clear ownership of the TPM.  This will delete the PO index.  Then, do not run the LCP script that you used previously.  It's ok not to have a PO policy when you're just doing initial testing.  The PS policy (also called the platform default policy) will be used if no PO policy is present.  Your current PS policy allows NPW signed ACMs to be used, so you should see a trusted boot once you delete the PO policy.

-Jeff

 

Thanks Jeff.

Clearing the TPM ownership has actually work and now I can test MLE and trusted boot.

I am going to install OpenAttestation tool on my server. Hopefully everything should run smoothly now.

Thanks again.

 

 

 

 

 

 

Glad to help.   

Thanks for confirming trusted boot is working for you now.

Leave a Comment

Please sign in to add a comment. Not a member? Join today