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
just a shortish question because I am a little baffled right now. I am programming a new MLE to be used with Intel TXT. We want to launch this within a running Linux (64Bit) - this should be perfectly possible afaik. I got most of it working, TXT is working (tboot would successfully boot on previous tests!), but now I get this error whenever I execute GETSEC[SENTER]: 0xC0000481.
I've been booting fine - created a new policy and now get the above error code - which appears to decode to Class C - Major error 8 - which appears to be an "Invalid RSDP" .
Since that's part of ACPI - I'm having a hard time figuring out what that really means?
I'm booting tboot to a 3.11.10 linux kernel and it is indeed booting and pcrs, including 17,18 and 19 are being extended. Perhaps I just don't understand the sequencing - the part that has me perplexed is where tboot goes into SENTER and then starts over again and succeeds - although SEXIT is never run - specifically this section. I guess my question is - why would it restart tboot?
What is the reasoning behind having a separate DRTM? Is there any security vulnerability associated with having just the static root of trust?
1) Hardware Microcode verifies BIOS ACM
2) BIOS ACM verifies BIOS
3) BIOS verifies its components
4) BIOS verifies the initial-program loader (IPL) and IPL configurations. In Linux, this would include GRUB and the GPT table or MBR.
You then have this gap where GRUB can load modules and run commands without anything getting measured.
Changes in MEBx settings are not reflected in PCRs.
Intel folks - the tboot mailing list shows
3 indices have been defined > list of indices for defined NV storage areas: > 0x10000001 0x50000001 0x50000003 > > The second two need to be there - the are LCP related indexes
Then of course Intel says we need 0x20000001 0x40000001 etc. for owner etc.
I actually have an ST Micro TPM and it came from Dell with
0x100f0000 - 0x50010000 and a couple others not mentioned anywhere - any light you can shed on required indexes ?
I note a number of error code questions - I have the error code document and so I can decode a good deal of it , but the minor error codes are vague. Perhaps they are vendor specific? In any case a detailed description which would allow trouble shooting would be great.
Is there such a document?
Put in a question yesterday - it didn't show up -
- Seite 1