Re: [tboot-devel] TXT SINIT ACM failure on power-cycling node

[Jan Schermer]

My HP z240 workstation occassionaly refuses to boot at all if I yank out the 
power cable while in TXT mode.
Solution: leave power disconnected for >5 minutes, then reset BIOS (yes, 
really).

I had similiar issues with Lenovo system.

I don’t think OEMs test anything...

Jan

> On 26 Feb 2018, at 22:52, Rich Persaud  wrote:
> 
> On TXT-enabled vPro client devices (e.g. Dell 7040) that have been tested 
> with OpenXT, Xen and OpenEmbedded measured launch [1], if you use the 
> hardware power switch to perform a non-graceful shutdown of an operating 
> system that was booted with TXT, the following will occur:
> 
>  (a)  User presses hardware power button to turn on the device.
>  (b)  Device powers on for a few seconds, then powers back off (TXT reset).
>  (c)  User presses hardware power button to turn on the device.
>  (d)  Device powers on normally, OS successfully completes measured launch.
> 
> Your issue sounds like a device-specific OEM BIOS defect, have you tried 
> contacting the OEM? Does it happen on servers from a different OEM? Which CPU 
> generation?
> 
> If there is interest in collaborating on OE/Yocto layers for TXT, TPM, 
> SecureBoot, we can arrange a conference call or ELC BoF.
> 
> Rich
> 
> [1] 
> https://openxt.atlassian.net/wiki/spaces/DC/pages/81035265/Measured+Launch+SRTM+and+DRTM
>  
> 
> 
> 
> On Feb 22, 2018, at 15:54, Nasim, Kam  > wrote:
> 
>> Hi folks,
>>  
>> We’ve been trying to integrate Tboot in our Boot sequence and have it 
>> working fine for the most part. We specify a default ANY Launch Control 
>> Policy (LCP) as main intention is to capture boot measurements in TPM PCRs 
>> and not really enforce a boot halt action.
>>  
>> I noticed that when I power cycle the node or any other kind of non-graceful 
>> restart, it stops at the Boot menu with the following Error:
>>  
>> Message
>> An issue is observed in the previous invocation of TXT SINIT Authenticated 
>> Code Module (ACM) because the TXT information stored in the TPM chip may be 
>> corrupted. 
>> Detailed Description
>> An issue in observed in the previous invocation of TXT SINIT Authenticated 
>> Code Module (ACM) because the TXT information stored in the TPM chip may be 
>> corrupted. 
>>  <>Recommended Response Action
>> Do one of the following: 1) Update the BIOS firmware. 2) Go to System Setup 
>> > System Security page, click the "Clear" option under TPM command. Restart 
>> the system, go to System Setup > System Security page, click the "Activate" 
>> option under TPM command, and then enable TXT.
>>  
>>  
>> I am able to continue past this but was wondering if there is any way to 
>> disable this. We don’t want to be manually doing this for all of our servers 
>> after a Power Cycle event.
>>  
>> Have others seen this? Is this a form of corruption in the ACM? How do I 
>> flush that state on a power cycle?
>>  
>>  
>> Thanks,
>> Kam
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org ! 
>> http://sdm.link/slashdot 
>> ___
>> tboot-devel mailing list
>> tboot-devel@lists.sourceforge.net 
>> https://lists.sourceforge.net/lists/listinfo/tboot-devel 
>> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org ! 
> http://sdm.link/slashdot___ 
> 
> tboot-devel mailing list
> tboot-devel@lists.sourceforge.net 
> https://lists.sourceforge.net/lists/listinfo/tboot-devel 
> 
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel

Re: [tboot-devel] SINIT ACM not present on a Workstation-class computer?

[Jan Schermer]

Thank you very much.
It's not a server so that's probably why they didn't bother.

Have a nice weekend
Jan

> On 18 Nov 2016, at 20:36, Sun, Ning <ning@intel.com> wrote:
> 
> BIOS-based SINIT ACM is a server TXT requirement, not a vPro requirement.
> We contacting HP to find the reason why SINIT ACM is not embedded in BIOS for 
> their workstation SKU Z240
>  
> Regards,
> -ning
>  
>  <>From: Jan Schermer [mailto:j...@schermer.cz <mailto:j...@schermer.cz>] 
> Sent: Friday, November 18, 2016 9:52 AM
> To: Justin King-Lacroix <justin.king-lacr...@cs.ox.ac.uk 
> <mailto:justin.king-lacr...@cs.ox.ac.uk>>
> Cc: tboot-devel@lists.sourceforge.net 
> <mailto:tboot-devel@lists.sourceforge.net>
> Subject: Re: [tboot-devel] SINIT ACM not present on a Workstation-class 
> computer?
>  
> Ah!
> I thought BIOS ACM = SINIT ACM embedded in BIOS...
> Now I see it's a pre-BIOS code actually.
>  
> In any case, TXT works on this system when I load the SINIT module manually, 
> but I was hoping it would have it embedded in BIOS like the M900...
> It's PITA because I use those systems to test server deployment (where SINIT 
> is always provided by the platform AFAIK), it's gonna be hard to make it 
> universal.
>  
> Any tips how to best handle SINIT provisioning? Should I detect the platform 
> and guess the right SINIT? Or should I simply load few of them and hope it 
> works with one of them?
>  
> Thanks
> Jan
>  
> On 18 Nov 2016, at 18:39, Justin King-Lacroix 
> <justin.king-lacr...@cs.ox.ac.uk <mailto:justin.king-lacr...@cs.ox.ac.uk>> 
> wrote:
>  
> IIRC aren't the BIOS ACM and SINIT ACM separate? (And the BIOS may or may not 
> contain an SINIT ACM.)
>  
> Of course, there might also be a bug in HP's BIOS, in which whatever 
> pointer/register needs to be initialised isn't. Wouldn't be the first.
>  
> On 18 November 2016 at 12:27, Jan Schermer <j...@schermer.cz 
> <mailto:j...@schermer.cz>> wrote:
> Hi,
> I just got HP Z240 workstation (i7-6700 cpu) and it seems to lack SINIT ACM 
> embedded in the BIOS
> I see this in one of the BIOS changelogs:
> • Updates Intel TXT BIOS ACM to v1.3.
> ^ shouldn't this mean it is there?
> 
> tboot says:
> TBOOT: checking if module  is an SINIT for this platform...
> TBOOT:   ACM size is too small: acmod_size=30c, sizeof(acm_hdr)=4
> TBOOT: checking if module  is an SINIT for this platform...
> TBOOT:   ACM size is too small: acmod_size=15, sizeof(acm_hdr)=4
> TBOOT: checking if module  is an SINIT for this platform...
> TBOOT:   ACM size is too small: acmod_size=66c5200, acm_hdr->size*4=c0c0c0c0
> TBOOT: no SINIT AC module found
> TBOOT: TXT.SINIT.BASE: 0xb1ed
> TBOOT: TXT.SINIT.SIZE: 0x5 (327680)
> TBOOT: SINIT ACM not provided.
> 
> 
> Is there really no embedded AC module here? I know I can sideload it, but I 
> was expecting it to be there (it is there on my other Workstation - Lenovo 
> M900, more-or-less the same specs and the same CPU).
> It claims to support vPro and I thought one of the requirements was embedded 
> SINIT AC module, but maybe I am wrong here...
> 
> 
> Thanks
> Jan
> 
> 
> --
> ___
> tboot-devel mailing list
> tboot-devel@lists.sourceforge.net <mailto:tboot-devel@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/tboot-devel 
> <https://lists.sourceforge.net/lists/listinfo/tboot-devel>
--
___
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel

Re: [tboot-devel] SINIT ACM not present on a Workstation-class computer?

[Jan Schermer]

Ah!
I thought BIOS ACM = SINIT ACM embedded in BIOS...
Now I see it's a pre-BIOS code actually.

In any case, TXT works on this system when I load the SINIT module manually, 
but I was hoping it would have it embedded in BIOS like the M900...
It's PITA because I use those systems to test server deployment (where SINIT is 
always provided by the platform AFAIK), it's gonna be hard to make it universal.

Any tips how to best handle SINIT provisioning? Should I detect the platform 
and guess the right SINIT? Or should I simply load few of them and hope it 
works with one of them?

Thanks
Jan

> On 18 Nov 2016, at 18:39, Justin King-Lacroix 
> <justin.king-lacr...@cs.ox.ac.uk> wrote:
> 
> IIRC aren't the BIOS ACM and SINIT ACM separate? (And the BIOS may or may not 
> contain an SINIT ACM.)
> 
> Of course, there might also be a bug in HP's BIOS, in which whatever 
> pointer/register needs to be initialised isn't. Wouldn't be the first.
> 
> On 18 November 2016 at 12:27, Jan Schermer <j...@schermer.cz 
> <mailto:j...@schermer.cz>> wrote:
> Hi,
> I just got HP Z240 workstation (i7-6700 cpu) and it seems to lack SINIT ACM 
> embedded in the BIOS
> I see this in one of the BIOS changelogs:
> • Updates Intel TXT BIOS ACM to v1.3.
> ^ shouldn't this mean it is there?
> 
> tboot says:
> TBOOT: checking if module  is an SINIT for this platform...
> TBOOT:   ACM size is too small: acmod_size=30c, sizeof(acm_hdr)=4
> TBOOT: checking if module  is an SINIT for this platform...
> TBOOT:   ACM size is too small: acmod_size=15, sizeof(acm_hdr)=4
> TBOOT: checking if module  is an SINIT for this platform...
> TBOOT:   ACM size is too small: acmod_size=66c5200, acm_hdr->size*4=c0c0c0c0
> TBOOT: no SINIT AC module found
> TBOOT: TXT.SINIT.BASE: 0xb1ed
> TBOOT: TXT.SINIT.SIZE: 0x5 (327680)
> TBOOT: SINIT ACM not provided.
> 
> 
> Is there really no embedded AC module here? I know I can sideload it, but I 
> was expecting it to be there (it is there on my other Workstation - Lenovo 
> M900, more-or-less the same specs and the same CPU).
> It claims to support vPro and I thought one of the requirements was embedded 
> SINIT AC module, but maybe I am wrong here...
> 
> 
> Thanks
> Jan
> 
> 
> --
> ___
> tboot-devel mailing list
> tboot-devel@lists.sourceforge.net <mailto:tboot-devel@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/tboot-devel 
> <https://lists.sourceforge.net/lists/listinfo/tboot-devel>
> 

--
___
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel

[tboot-devel] SINIT ACM not present on a Workstation-class computer?

[Jan Schermer]

Hi,
I just got HP Z240 workstation (i7-6700 cpu) and it seems to lack SINIT ACM 
embedded in the BIOS
I see this in one of the BIOS changelogs:
• Updates Intel TXT BIOS ACM to v1.3.
^ shouldn't this mean it is there?

tboot says:
TBOOT: checking if module  is an SINIT for this platform...
TBOOT:   ACM size is too small: acmod_size=30c, sizeof(acm_hdr)=4
TBOOT: checking if module  is an SINIT for this platform...
TBOOT:   ACM size is too small: acmod_size=15, sizeof(acm_hdr)=4
TBOOT: checking if module  is an SINIT for this platform...
TBOOT:   ACM size is too small: acmod_size=66c5200, acm_hdr->size*4=c0c0c0c0
TBOOT: no SINIT AC module found
TBOOT: TXT.SINIT.BASE: 0xb1ed
TBOOT: TXT.SINIT.SIZE: 0x5 (327680)
TBOOT: SINIT ACM not provided.


Is there really no embedded AC module here? I know I can sideload it, but I was 
expecting it to be there (it is there on my other Workstation - Lenovo M900, 
more-or-less the same specs and the same CPU).
It claims to support vPro and I thought one of the requirements was embedded 
SINIT AC module, but maybe I am wrong here...


Thanks 
Jan


--
___
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel

Re: [tboot-devel] garbage characters on the command line

[Jan Schermer]

We already solved this (unless it's come back).

It was fixed by this commit:
https://sourceforge.net/p/tboot/code/ci/356ad4b1d363c70d7b25907f812bd411a28eecd3/
 


However, this was after 1.9.4 was tagged and distributions probably didn't 
patch their versions...

I recommend you use latest trunk, packages and tagged versions are quite 
outdated and possibly even dangerous to rely on.

Jan


> On 3 Nov 2016, at 20:10, Brian E Luckau  wrote:
> 
> Hi,
> 
> We have had issues with tboot 1.8.x and 1.9.4, and seeing garbage 
> characters on the cmdline at the end.  We've seen this on multiple 
> different hardware types, different  OSes(RHEL 7.3, Centos 7.2, 
> SLES12sp2). We are using PXE boot in all the cases that I'm aware of.
> 
> It looks like we are passing tboot a good command line and then tboot 
> passes control to the kernel, at which time the command line has the 
> extra characters on it.
> 
> TBOOT: verifying module "
> (tftp)/boot/sles12sp2/vmlinuz-4.4.21-69-default MAC=[snipped]...
> [...] crashkernel=256M"...
> TBOOT:   OK : d6 ce 7b 29 41 a3 3a d9 3a b8 1a 69 55 88 9b 66 49 4c 80 66
> TBOOT: verifying module "
> (tftp)/boot/sles12sp2/initrd-4.4.21-69-default"...
> 
> Then it transfers control to the kernel.  At this point the kernel shows that 
> the
> cmdline it got is corrupted.
> 
> [0.00] Linux version 4.4.21-69-default (geeko@buildhost) (gcc version 
> 4.8.5 (SUSE Linux) ) #1 SMP Tue Oct 25 10:58:20 UTC 2016 (9464f67)
> [0.00] Command line: (tftp)/boot/sles12sp2/vmlinuz-4.4.21-69-default 
> [snipped ... ] crashkernel=256Mt ufh
> 
> I'm hoping to find there is a patch, etc. for tboot to rectify this.
> 
> --
> 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

--
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

Re: [tboot-devel] user-provided AC modules

[Jan Schermer]

I'd also like to know this - including all the ACMs in a distribution seems... 
hackish.

This is most likely vendor-specific.
Older machines that I tried didn't include it (old Thinkpads for example), the 
newest one that didn't include it that I've seen was of ~2014 vintage (pre-EFI 
methinks].
Servers should include it (always?), but if they don't then the vendor doesn't 
care, and then it's doubtul how well it will work anyway.

Jan

> On 20 Sep 2016, at 18:37, Daniel Mueller  wrote:
> 
> Hi,
> 
> Looking at the tboot source code it seems to support finding and installing a 
> user-provided AC module. Is this feature actually used with recent systems or 
> do all systems ship with an ACM installed?
> 
> I found the following line in the TXT development guide 
> :
> 
> Since the TXT architecture requires that BIOS provide at least one BIOS ACM, 
> NumAcms must always be greater than 0.
> So it appears an ACM must be installed. Are there any known systems violating 
> this constraint?
> 
> Thanks,
> Daniel
> 
> --
> ___
> tboot-devel mailing list
> tboot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/tboot-devel

--
___
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel

Re: [tboot-devel] PCR values?

[Jan Schermer]

Do you have the correct TPM driver loaded in kernel? Does /sys/class/misc/tpm0 
exist?
AFAIK you can TXT-launch a kernel that has no driver (as it is likely loaded in 
initramfs or later anyway), txt-stat will probably also work even without a 
working in the kernel...

Jan


> On 01 Sep 2016, at 16:32, Brian E Luckau  wrote:
> 
> In the past using tboot 1.8.x and versions of trousers, tpm tools, etc, 
> etc. that came with the distros, I was able to see the PCR values with:
> 
> cat /sys/class/misc/tpm0/device/pcrs
> 
> Currently I'm in CentOS 7.2 and have compliled and installed tboot 1.9.4.  I 
> see this, which with my limited knowledge base tells me something is goign 
> right:
> 
> 
> [root@server0 ~]# txt-stat | grep measured
>  TXT measured launch: TRUE
> TBOOT: measured launch succeeded
> 
> [root@server0 ~]# txt-stat | grep senter
> senter_done: TRUE
> 
> 
> Any idea why I can't see the PCR values?
> 
> --
> ___
> tboot-devel mailing list
> tboot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/tboot-devel


--
___
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel

Re: [tboot-devel] Crash/system reset with linux 4.4

[Jan Schermer]

Just FYI - I'm using tboot with 4.4 kernels (Ubuntu 16.04) and I haven't had 
this issue

Jan

> On 03 Aug 2016, at 05:35, Sun, Ning  wrote:
> 
> There is an explanation in README of tboot source code about 'min_ram' 
> parameter: https://sourceforge.net/p/tboot/code/ci/default/tree/.
> To identify this issue as a generic or a specific one with Qubes OS, needs to 
> run Qubes OS  and tboot on several different platforms from different vendors 
> if possible.
> There are new releases of tboot available since tboot 1.8.2, to help verify 
> if tboot has a bug relevant to this crash/reset.
> 
> -ning
> 
> -Original Message-
> From: Chris Laprise [mailto:tas...@openmailbox.org] 
> Sent: Tuesday, August 02, 2016 5:54 PM
> To: tboot-devel@lists.sourceforge.net
> Subject: [tboot-devel] Crash/system reset with linux 4.4
> 
> Hello,
> 
> 
> On Qubes OS 3.2rc2, a tboot-based boot sequence will fail with a system reset 
> unless the 'min_ram=0x200' parameter is specified in grub. See Qubes 
> issue #2155:
> 
> https://github.com/QubesOS/qubes-issues/issues/2155
> 
> Currently, Qubes uses tboot version 1.8.2 from the Fedora 23 repository. 
> The other relevant components are Linux kernel 4.4.14 and Xen 4.6.1. If Linux 
> is downgraded to 4.2 then the system is able to boot without crashing.
> 
> This parameter would normally be used to rectify a milder condition where the 
> system boots with less memory available than it should. Using it to avoid a 
> catastrophic crash does not seem right, so I'd like to ask what is the best 
> course of action from the tboot devs: Is this a bug in tboot or Linux? Should 
> Qubes devs consider using 'min_ram' for all tboot installations? Would it be 
> worth the trouble to try upgrading tboot to the current version? And if so, 
> are signatures available for the tboot code?
> 
> Chris
> 
> 
> --
> ___
> tboot-devel mailing list
> tboot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/tboot-devel
> 
> --
> ___
> tboot-devel mailing list
> tboot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/tboot-devel


--
___
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel

Re: [tboot-devel] Loading multiboot(2) images

[Jan Schermer]

The problem is you didn't attach it but pasted it inline (or so it appears).
When I copy it, it lacked space indentations on some lines and patch 
complained. I had to copy it in Textedit I think...

Jan

> On 16 Jun 2016, at 15:53, Ahmed, Safayet (GE Global Research, US) 
>  wrote:
> 
> I'm sorry, Ning. I'm not sure what went wrong.
> 
> I've attached the patch again below. It applies to Changeset 451 
> (356ad4b1d363).
> 
> I generated the patch using the command "hg diff -apU 3 > 
> ../tboot-16-06-2016.patch".
> 
> I was able to apply the patch from the tboot source directory using the 
> command "patch -p 1 < ../tboot-16-06-2016.patch".
> 
> Please let me know if this works
> 
>  PATCH STARTS BELOW THIS LINE 
> **
> diff -r 356ad4b1d363 tboot/common/elf.c
> --- a/tboot/common/elf.c  Thu Jun 09 10:53:29 2016 -0700
> +++ b/tboot/common/elf.c  Thu Jun 16 09:07:21 2016 -0400
> @@ -145,9 +145,7 @@ bool is_elf_image(const void *image, siz
> return false;
> }
> 
> -#if 0
> -static bool get_elf_image_range(const elf_header_t *elf, void **start,
> -void **end)
> +bool get_elf_image_range(const elf_header_t *elf, void **start, void **end)
> {
> uint32_t u_start, u_end;
> 
> @@ -188,7 +186,6 @@ static bool get_elf_image_range(const el
> return true;
> }
> }
> -#endif
> 
> bool expand_elf_image(const void *image, void **entry_point)
> {
> diff -r 356ad4b1d363 tboot/common/loader.c
> --- a/tboot/common/loader.c   Thu Jun 09 10:53:29 2016 -0700
> +++ b/tboot/common/loader.c   Thu Jun 16 09:07:21 2016 -0400
> @@ -3,6 +3,7 @@
>  *   binaries
>  *
>  * Copyright (c) 2006-2013, Intel Corporation
> + * Copyright (c) 2016 Real-Time Systems GmbH
>  * All rights reserved.
>  *
>  * Redistribution and use in source and binary forms, with or without
> @@ -64,7 +65,7 @@ extern tboot_shared_t _tboot_shared;
> 
> /* multiboot struct saved so that post_launch() can use it (in tboot.c) */
> extern loader_ctx *g_ldr_ctx;
> -
> +extern bool get_elf_image_range(const elf_header_t *elf, void **start, void 
> **end);
> extern bool is_elf_image(const void *image, size_t size);
> extern bool expand_elf_image(const elf_header_t *elf, void **entry_point);
> extern bool expand_linux_image(const void *linux_image, size_t linux_size,
> @@ -769,6 +770,98 @@ unsigned long get_mbi_mem_end_mb1(const 
> return PAGE_UP(end);
> }
> 
> +/*
> + * Move all mbi components/modules/mbi to end of memory
> + */
> +static bool move_modules_to_high_memory(loader_ctx *lctx)
> +{
> +uint64_t max_ram_base = 0,
> + max_ram_size = 0;
> +uint32_t memRequired = 0;
> +
> +uint32_t module_count = get_module_count(lctx);
> +
> +for ( unsigned int i = 0; i < module_count; i++ )
> +{
> +module_t *m = get_module(lctx,i);
> +memRequired += PAGE_UP(m->mod_end - m->mod_start);
> +}
> +
> +get_highest_sized_ram(memRequired, 0x1ULL, _ram_base, 
> _ram_size);
> +if(!max_ram_base || !max_ram_size)
> +{
> +printk(TBOOT_INFO"ERROR No suitable memory area found for image 
> relocation!\n");
> + printk(TBOOT_INFO"required 0x%X\n", memRequired);
> +return false;
> +}
> +
> +printk(TBOOT_INFO"highest suitable area @ 0x%llX (size 0x%llX)\n", 
> max_ram_base, max_ram_size);
> +
> +unsigned long target_addr =  PAGE_DOWN(max_ram_base + max_ram_size);
> +
> +for ( unsigned int i = 0; i < module_count; i++ )
> +{
> +unsigned long base, size;
> +module_t *m = get_module(lctx,i);
> +base = m->mod_start;
> +size = m->mod_end - m->mod_start;
> +printk(TBOOT_INFO"moving module %u (%lu bytes) from 0x%08X ", i, 
> size, (uint32_t)base);
> +
> +//calculate target addresses
> +target_addr = PAGE_DOWN(target_addr - size);
> +printk(TBOOT_INFO"to 0x%08X\n", (uint32_t)target_addr);
> +
> +memcpy((void *)target_addr, (void *)base, size);
> +m->mod_start = target_addr;
> +m->mod_end = target_addr + size;
> +}
> +
> +return true;
> +}
> +
> +/*
> + * Move any mbi components/modules/mbi that just above the kernel
> + */
> +static bool move_modules_above_elf_kernel(loader_ctx *lctx, elf_header_t 
> *kernel_image)
> +{
> +if (LOADER_CTX_BAD(lctx))
> +return false;
> +
> +/* get end address of loaded elf image */
> +void *elf_start=NULL, *elf_end=NULL;
> +if ( !get_elf_image_range(kernel_image, _start, _end) )
> +{
> +printk(TBOOT_INFO"ERROR: failed tget elf image range\n");
> +}
> +
> +printk(TBOOT_INFO"ELF kernel top is at 0x%X\n", (uint32_t)elf_end);
> +
> +/* keep modules page aligned */
> +uint32_t target_addr = PAGE_UP((uint32_t)elf_end);
> +
> +uint32_t module_count = get_module_count(lctx);
> +
> +for ( unsigned int i = 0; i < module_count; i++ )
> +{
> +unsigned long base, size;
> +

[tboot-devel] Uniqueness of PCR-18 with pcr_map=da?

[Jan Schermer]

Hi,
can someone please tell me from experience whether PCR-18 can be treated as 
non-changing between different servers or platforms when pcr_map=da is used and 
I use the same signing key?

Can I safely assume that PCR-18 will be the same on different servers or 
different brands of servers even? Docs say the following and I'm not sure - 
especially the last point would be troubling but I don't think it changes when 
I use a different tboot binary (that should produce a different hash, right?). 

The following hashes are extended to PCR18 in the order given:

•   DIGEST of public key modulus used to verify SINIT signature.

•   DIGEST of Processor S-CRTM status coded as DWORD – same value as 
extended to PCR17.

•   DIGEST of Capability field of OsSinitData table, coded as DWORD – 
same value as extended to PCR17.

•   DIGEST of PolicyControl field of used policy (platform supplier 
(PS) or platform owner (PO)) coded as DWORD – same value as extended to PCR17.

•   DIGEST of LCP – DIGEST of concatenation of hashes of lists 
containing matching elements. If no policy, for 1.2 family, this digest is 
zero; for 2.0 family, it is DIGEST(0x0)


Thanks
Jan
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports. http://pubads.g.doubleclick.net/gampad/clk?id=1444514421=/41014381
___
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel

Re: [tboot-devel] Loading multiboot(2) images

[Jan Schermer]

My interest is not completely ingenuous, I hit an issue with memory corruption 
last week when PXE booting tboot. That's with  arather large (200MiB) initrd so 
I was wondering if it's somehow related (your patch does not fix my issue, 
though).
We found and fixed my issue (or at least the symptom I'm seeing), but I have a 
feeling the root cause is something like this.

Jan


> On 13 Jun 2016, at 17:38, Ahmed, Safayet (GE Global Research, US) 
> <safayet.ah...@ge.com> wrote:
> 
> Thanks for testing this so quickly, Jan.
> 
> I am aware of the code from the patch you mention. However, just moving 
> modules above the memory occupied by TBoot is not always enough for a 
> successful launch (especially when your kernel is large or you have a whole 
> bunch of modules).
> 
> Safayet
> 
> -----Original Message-
> From: Jan Schermer [mailto:j...@schermer.cz] 
> Sent: Monday, June 13, 2016 11:32 AM
> To: Ahmed, Safayet (GE Global Research, US)
> Cc: tboot-devel@lists.sourceforge.net
> Subject: EXT: Re: [tboot-devel] Loading multiboot(2) images
> 
> I just wonder how it relates to this patch?
> https://urldefense.proofpoint.com/v2/url?u=https-3A__sourceforge.net_p_tboot_mailman_message_28249969_=CwIFAg=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI=lDSLRzn8YUPmwjLuy9Ek9Dy-T15T3uK505eKqf1EFfg=0M9z_fwbfXh2WiB5AcWfW3ePsEIv1JkglOMQpbHgvK8=y-rxEOzbQBAUMjBfGgzT-DLHdCAibJzcGhO5ovi0-f8=
>  
> 
> For what it's worth, I tested this patch on my system, boots fine using PXE 
> GRUB2 multiboot.
> 
> Jan
> 
> 
> 
>> On 13 Jun 2016, at 16:52, Ahmed, Safayet (GE Global Research, US) 
>> <safayet.ah...@ge.com> wrote:
>> 
>> We have been experimenting with measured launch of environments other than 
>> Linux and Xen, such as the RTS hypervisor and some real-time operating 
>> systems. 
>> 
>> We have seen a recurring issue in some cases with the way TBoot launches 
>> multiboot/multiboot2 environments. Namely, when loading the ELF image, TBoot 
>> overwrites the kernel ELF image and modules.
>> 
>> Developers at RTS have made changes to "tboot/common/loader.c" and 
>> "tboot/common/elf.c" that addresses this issue:
>> When the follow-on kernel is a multiboot or multiboot2 kernel, move the 
>> modules to the top of memory as reported in the E820 map. Then, after 
>> loading the kernel ELF binary into its final location in memory, move the 
>> modules to a location just above the kernel.
>> 
>> The patches for these changes are below.
>> 
>> thanks,
>> 
>> Safayet
>> 
>> Signed-off-by: Raphael Baum  <r.b...@real-time-systems.com>
>> Signed-off-by: Safayet Ahmed <safayet.ah...@ge.com>
>> 
>> diff -r 6531a0eaf369 tboot/common/elf.c
>> --- a/tboot/common/elf.cWed May 18 10:13:24 2016 -0700
>> +++ b/tboot/common/elf.cMon Jun 13 10:19:02 2016 -0400
>> @@ -146,7 +146,5 @@
>> }
>> 
>> -#if 0
>> -static bool get_elf_image_range(const elf_header_t *elf, void **start,
>> -void **end)
>> +bool get_elf_image_range(const elf_header_t *elf, void **start, void 
>> +**end)
>> {
>>uint32_t u_start, u_end;
>> @@ -189,5 +187,4 @@
>>}
>> }
>> -#endif
>> 
>> bool expand_elf_image(const void *image, void **entry_point) diff -r 
>> 6531a0eaf369 tboot/common/loader.c
>> --- a/tboot/common/loader.cWed May 18 10:13:24 2016 -0700
>> +++ b/tboot/common/loader.cMon Jun 13 10:19:02 2016 -0400
>> @@ -4,4 +4,5 @@
>> *
>> * Copyright (c) 2006-2013, Intel Corporation
>> + * Copyright (c) 2016 Real-Time Systems GmbH
>> * All rights reserved.
>> *
>> @@ -65,5 +66,5 @@
>> /* multiboot struct saved so that post_launch() can use it (in 
>> tboot.c) */ extern loader_ctx *g_ldr_ctx;
>> -
>> +extern bool get_elf_image_range(const elf_header_t *elf, void 
>> +**start, void **end);
>> extern bool is_elf_image(const void *image, size_t size); extern bool 
>> expand_elf_image(const elf_header_t *elf, void **entry_point); @@ 
>> -770,4 +771,96 @@ }
>> 
>> +/*
>> + * Move all mbi components/modules/mbi to end of memory  */ static 
>> +bool move_modules_to_high_memory(loader_ctx *lctx) {
>> +uint64_t max_ram_base = 0,
>> + max_ram_size = 0;
>> +uint32_t memRequired = 0;
>> +
>> +uint32_t module_count = get_module_count(lctx);
>> +
>> +for ( unsigned int i = 0; i < module_count; i++ )
>> +{
>> +module_t *m = get_module(lctx,i);
>> +memRequired += PAGE_UP(m->mod_end - m->mod_sta

[tboot-devel] TPM provisioning (SuperMicro)

[Jan Schermer]

Hi,
SuperMicro sells TPMs either unprovisioned, provisioned as "client txt" 
(workstation/desktop processors) or provisioned "server txt".
I'm having a hard time getting the server provisioned type, so I'll probably 
have to provision them myself when they arrive.

There are instructions (https://www.supermicro.com/manuals/other/TPM.pdf) on 
how to provision the TPM for either use, but I was wondering - is it possible 
to provision it using the standard Trousers stack instead of the Intel 
utilities?
I think it should be possible to create the needed indexes and lock the NVRAM 
using tpm-tools, but I'm not sure what else has to be done, or whether there 
need to be some special contents in the indexes...

Thanks
Jan
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
___
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel

[tboot-devel] tboot corrupting cmdline when started form PXE?

[Jan Schermer]

Hi,
I've seen this happen with both iPXE and GRUB now.

For example if I load tboot+linux like this in GRUB:

multiboot boot/tboot.gz logging=vga,serial,memory
module boot/Ubuntu-TXT-16.04-x86_64-linux interface=auto 
url=http://something.somewhere ramdisk_size=10800 root=/dev/rd/0 rw auto 
hostname=test BOOTIF=${net_pxe_mac} console-setup/ask_detect=false 
console-setup/layout=USA console-setup/variant=USA 
keyboard-configuration/layoutcode=us localechooser/translation/warn-light=true 
localechooser/translation/warn-severe=true locale=en_US brm
module boot/Ubuntu-TXT-16.04-x86_64-initrd.gz

System loads fine, but /proc/cmdline contains ~20 characters of random garbage 
appended to the original cmdline contents.



I first saw it wheb trying to load Foreman Discovery Image - a ramdisk based on 
CentOS 7.
I decided to ignore it then and switched to GRUB, this fixed booting the 
Discovery Image (no /cmdline corruption).

Next step is provisioning = booting Ubuntu preseed, and /proc/cmdline is 
corrupted there now.

So I'm pretty sure that it is tboot corrupting the cmdline (is it terminated 
differently in PXE environment? Some padding needed?)

I'm not sure how reproducible it is. While I can trigger it every time in those 
combinations, apparently with some modules it boots fine (because FDI boots 
fine...)

Has anybody encountered this before? Any PXE users here?

Thanks

Jan
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
___
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel

[tboot-devel] Help interpreting this launch failure?

[Jan Schermer]

Hello,
I am seeing this launch failure on a Lenovo T510 laptop (attached is the output 
of txt-stat with nonfatal policy).
Can someone take a look and let me know what the problem could be?

This looks suspect:

TBOOT: verifying module 1 of mbi (b54000 - 6e691ff) in e820 table
 (range from 00b54000 to 06e69200 is in E820_MIXED)
TBOOT: : failed.
TBOOT: verification of post-launch failed.

What is this? Is this a grub module? Because I see verification for those 
succeeding:

TBOOT: verifying policy 
TBOOT: verifying module "
root=/dev/mapper/vg_system-lv_root ro libata.allow_tpm=1 intel_iommu=on"...
TBOOT:   OK : 7a fa 7c 0f 94 87 68 51 cf 3e 30 61 bf 69 a0 7a be 08 0c 90 
TBOOT: verifying module ""...
TBOOT:   OK : b7 91 d0 50 5f aa 12 f7 c6 9a 7d b8 fa 16 ef 74 74 b4 b4 53 
TBOOT: verifying module ""...
TBOOT:   OK : e7 0a 66 8c 40 90 4d d5 05 31 cc 1b df 54 0e e6 d8 53 03 0e 
TBOOT: all modules are verified
(all the hashes match the policy)


Also, do I have to include the SINIT ACM module in my VLP? That was my original 
suspect, but I moved it below other modules in grub so I guess it should not 
matter. My other platform works flawlessly, now I came back to trying it on a 
laptop and hit this...


Thanks for any ideas...

Jan



Intel(r) TXT Configuration Registers:
STS: 0x000188c1
senter_done: TRUE
sexit_done: FALSE
mem_config_lock: TRUE
private_open: TRUE
locality_1_open: TRUE
locality_2_open: TRUE
ESTS: 0x00
txt_reset: FALSE
E2STS: 0x0006
secrets: TRUE
ERRORCODE: 0x
DIDVID: 0x001fa0008086
vendor_id: 0x8086
device_id: 0xa000
revision_id: 0x1f
FSBIF: 0x
QPIIF: 0x9d003000
SINIT.BASE: 0xbf70
SINIT.SIZE: 131072B (0x2)
HEAP.BASE: 0xbf72
HEAP.SIZE: 917504B (0xe)
DPR: 0xbf800041
lock: TRUE
top: 0xbf80
size: 4MB (4194304B)
PUBLIC.KEY:
54 de 8b 2b fc 79 39 df 68 75 9b 12 55 2d 01 c8 
e0 2b e1 a0 99 68 16 c9 8e 9e b3 00 71 92 37 13 

***
 TXT measured launch: TRUE
 secrets flag set: TRUE
***
TBOOT log:
 max_size=32706
 zip_count=0
 curr_pos=24766
 buf:
TBOOT: *** TBOOT ***
TBOOT:2016-05-26 14:28 +0200 449:6531a0eaf369
TBOOT: *
TBOOT: command line: logging=serial,vga,memory pcr_map=da
TBOOT: IA32_FEATURE_CONTROL_MSR: ff03
TBOOT: CPU is SMX-capable
TBOOT: CPU is VMX-capable
TBOOT: SMX is enabled
TBOOT: TXT chipset and all needed capabilities present
TBOOT: IA32_FEATURE_CONTROL_MSR: ff03
TBOOT: CPU is SMX-capable
TBOOT: CPU is VMX-capable
TBOOT: SMX is enabled
TBOOT: TXT chipset and all needed capabilities present
TBOOT: BSP is cpu 0
TBOOT: original e820 map:
TBOOT:   - 0009e800  (1)
TBOOT:  0009e800 - 000a  (2)
TBOOT:  000dc000 - 0010  (2)
TBOOT:  0010 - bee7c000  (1)
TBOOT:  bee7c000 - bee82000  (2)
TBOOT:  bee82000 - bef5f000  (1)
TBOOT:  bef5f000 - bef71000  (2)
TBOOT:  bef71000 - beff2000  (4)
TBOOT:  beff2000 - bf00f000  (2)
TBOOT:  bf00f000 - bf06f000  (1)
TBOOT:  bf06f000 - bf268000  (2)
TBOOT:  bf268000 - bf2e8000  (4)
TBOOT:  bf2e8000 - bf30f000  (2)
TBOOT:  bf30f000 - bf317000  (1)
TBOOT:  bf317000 - bf31f000  (2)
TBOOT:  bf31f000 - bf36b000  (1)
TBOOT:  bf36b000 - bf377000  (4)
TBOOT:  bf377000 - bf37a000  (3)
TBOOT:  bf37a000 - bf381000  (4)
TBOOT:  bf381000 - bf382000  (3)
TBOOT:  bf382000 - bf38b000  (4)
TBOOT:  bf38b000 - bf38c000  (3)
TBOOT:  bf38c000 - bf39f000  (4)
TBOOT:  bf39f000 - bf3ff000  (3)
TBOOT:  bf3ff000 - bf40  (1)
TBOOT:  bf80 - c000  (2)
TBOOT:  e000 - f000  (2)
TBOOT:  feaff000 - feb0  (2)
TBOOT:  fec0 - fec1  (2)
TBOOT:  fed0 - fed00400  (2)
TBOOT:  fed1c000 - fed9  (2)
TBOOT:  fee0 - fee01000  (2)
TBOOT:  ff00 - 0001  (2)
TBOOT:  0001 - 00013800  (1)
TBOOT: checking if module  is an SINIT for this platform...
TBOOT: chipset production fused: 1
TBOOT: chipset ids: vendor: 0x8086, device: 0xa000, revision: 0x1f
TBOOT: processor 

[tboot-devel] OT: Most generic way to provision TXT on bare metal?

[Jan Schermer]

Hi,
are there any tools available for provisioning/enabling Intel TXT on bare metal 
servers? I'd like to avoid vendor-specific tools as much as possible.
What I'm looking for is either some toolkit able to enable TPM and TXT in BIOS 
of several vendors remotely (using BMC/IPMI), or some way to do that offline in 
a simple way
(e.g. resetting CMOS with a jumper and then booting some tool from a flash 
drive).

Does something like this exist? I usually try to be vendor-agnostic but this 
seems like a huge PITA...
How do you handle it?

Thanks
Jan
--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
___
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel

Re: [tboot-devel] booting tboot directly as EFI STUB?

[Jan Schermer]

Hi!
I think I might have run into some bugs, but so far I blame myself and not the 
platform.

My primary test tool was a Thinkpad T510 with vPro (not really a new machine), 
and it worked well enough for trying out TPM, figuring out how PCRs behave (on 
this platform only of course) and testing SED functionality on a SSD.

When I went to try tboot it booted without problem until I wrote LCP policy 
into NVRAM -> bootloop. I have a movie of the boot sequence if anyone is 
interested.
I'm going to try on HP DL160 Gen9 with TPM soon, let's see how that works, I 
still assume I don't know what I'm doing so I'm not pointing fingers at the 
platform yet.

>From what I gather Intel is pretty good at producing great tech, but poor at 
>marketing it - I've been working as a sysadmin (with some curiosity in sec) 
>for 17 years and I also thought TPM was a "smartcard" and that TXT is some 
>sort of NX bit extension. Oh how wrong I was. Even worse, my peers have no 
>idea either!
Let's hope TXT will be around for a while before they deprecate it, not sure 
what Intel's track record is in this area...

I actually had a meeting with Intel representative last week and he tried 
pushing TXT for attestation (since that was his understading of my needs until 
then).
My feeling is they are serious about it - after all it's what openstack 
attestation service uses (right?), vmware, hytrust, mcaffee - I'm not implying 
there's any security in it, but it's cheap compliance proof for those that need 
that kind of thing.

Jan




> On 19 Apr 2016, at 00:58, Dr. Greg Wettstein <g...@wind.enjellic.com> wrote:
> 
> On Apr 18,  8:55pm, Jan Schermer wrote:
> } Subject: Re: [tboot-devel] booting tboot directly as EFI STUB?
> 
> Good afternoon, I hope this note finds the day going well for
> everyone.
> 
>>>> -Original Message-
>>>> From: Jan Schermer [mailto:j...@schermer.cz] 
>>>> Sent: Monday, April 18, 2016 4:59 AM
>>>> To: tboot-devel@lists.sourceforge.net
>>>> Subject: [tboot-devel] booting tboot directly as EFI STUB?
>>>> 
>>>> Hello,
>>>> 
>>>> is it possible to add support for loading tboot directly instead
>>>> of using GRUB, in the same way Linux kernel supports it?
>>>> https://www.kernel.org/doc/Documentation/efi-stub.txt
>>>> 
>>>> This would greatly simplify the setup of tboot and remove one
>>>> unnecessary component (grub) which presents a quite large attack
>>>> surface.
>>>> 
>>>> This way tboot would get measured by BIOS directly into CRTM,
>>>> and we could immediately follow DRTM from here...  And I could
>>>> maybe sign the tboot binary for Secure Boot instead of using
>>>> poorly-documented GRUB :-)
>>> 
>>> On 18 Apr 2016, at 18:31, Sun, Ning <ning@intel.com> wrote:
>>> 
>>> Hi Jan,
>>> 
>>> Thanks for your email, currently tboot works with grub on both
>>> UEFI and legacy platforms.  Meanwhile, we are working on a PoC of
>>> UEFI 64 bit tboot, which will support multiple usages including
>>> what you mentioned in your email.  As this work is non-trivial,
>>> any suggestions/proposals are welcome!
>>> 
>>> Thanks,
>>> -Ning
>>> 
>> Thank you for your reply.
>> 
>> I am new to tboot, now in the process of designing our own PoC
>> around it.
>> 
>> I am also only a user (sorry for invading your -devel list) but so
>> far I can point to those areas for improvement from my perspective:
>> 
>> 1) documentation
>> 
>>  - examples! (gentoo wiki is a prime example of how it can
>> organically work, not sure if tboot community is large enough and
>> NDA-less for it to work, though).
>> 
>>  - some better docs for policy tools!
>> For example
>> man page of lcp_crtpolelt:
>>  [--ctrl pol-elt-ctr1] PolEltControl field (hex or decimal)
>> 
>> Now try googling "PolEltControl" :) or perhaps I'm not supposed to
>> care about that? :) (other tools have --ctrl parameter as well, and
>> I have no idea about those either)
>> 
>> Also, this seems to be a common theme to things TCG-related, like
>> TPM. I actually have to revert to ordering real books from Amazon to
>> get any real-world information it seems.
>> 
>> Or for example better introduction to tboot's own policy (what it
>> does, how it relates to LCP, when it is useful and when not - I
>> confess that I'm confused) There's more, but I'm still learning so
>> I'll ask after reading the TCG specs and other docs 

Re: [tboot-devel] booting tboot directly as EFI STUB?

[Jan Schermer]

Thank you for your reply.
I am new to tboot, now in the process of designing our own PoC around it.

I am also only a user (sorry for invading your -devel list) but so far I can 
point to those areas for improvement from my perspective:

1) documentation
- examples! (gentoo wiki is a prime example of how it can organically 
work, not sure if tboot community is large enough and NDA-less for it to work, 
though).
- some better docs for policy tools!
For example
man page of lcp_crtpolelt:
  [--ctrl pol-elt-ctr1] PolEltControl field (hex or decimal)
Now try googling "PolEltControl" :) or perhaps I'm not supposed to care about 
that? :)
(other tools have --ctrl parameter as well, and I have no idea about those 
either)
Also, this seems to be a common theme to things TCG-related, like TPM. I 
actually have to revert to ordering real books from Amazon to get any 
real-world information it seems.

Or for example better introduction to tboot's own policy (what it does, how it 
relates to LCP, when it is useful and when not - I confess that I'm confused)
There's more, but I'm still learning so I'll ask after reading the TCG specs 
and other docs again in case if missed something.

2) Some utility to decode the SINIT error codes (since you're from Intel... :)
I tried decoding them but my sinit is ancient, and the error codes are not 
listed for it anywhere

3) Better error reporting
Took me a while before I found out I don't have the necessary NVRAM indexes, 
the error message was not helpful.
This was because I tried copy an example that ommited creating those 
areas, now it feels natural once I figured (almost) how some things work, but 
for someone new this might be an unnecessary obstacle. I guess it comes back to 
documentation...


Btw I am looking for a consultant ($, but not big $$$ for now :), preferably 
someone with knowledge about TPM, TXT (or any form of measured/verified/trusted 
launch), and possibly SED drives. It's a sad reality that everyone around me 
never used UEFI apart from reinstalling Windows on a gf's laptop, and TPM is 
synonymous with "smartcard"...

My goal is to have the OS installed on SED drives that get decrypted by a key 
sealed by TPM to specific PCRs (attesting that my vmlinuz/initramfs are 
running) to prevent copying the installation and tampering ("integrity" comes 
by "proof of decryption" in my current scenario). Sounds simple in theory but I 
get stopped by me not having the knowledge, nobody around me having the 
knowledge and google refusing to find the knowledge. Also, all vendors are 
surprisingly clueless about any of this(?!) and all focus seems to be on 
workstations.

Is there someone who might be able to help me on this?

Thanks
Jan



> On 18 Apr 2016, at 18:31, Sun, Ning <ning@intel.com> wrote:
> 
> Hi Jan,
> 
> Thanks for your email, currently tboot works with grub on both UEFI and 
> legacy platforms.
> Meanwhile, we are working on a PoC of UEFI 64 bit tboot, which will support 
> multiple usages including what you mentioned in your email.
> As this work is non-trivial, any suggestions/proposals are welcome!
> 
> Thanks,
> -Ning
> 
> -Original Message-
> From: Jan Schermer [mailto:j...@schermer.cz] 
> Sent: Monday, April 18, 2016 4:59 AM
> To: tboot-devel@lists.sourceforge.net
> Subject: [tboot-devel] booting tboot directly as EFI STUB?
> 
> Hello,
> is it possible to add support for loading tboot directly instead of using 
> GRUB, in the same way Linux kernel supports it?
> https://www.kernel.org/doc/Documentation/efi-stub.txt
> 
> This would greatly simplify the setup of tboot and remove one unnecessary 
> component (grub) which presents a quite large attack surface.
> 
> This way tboot would get measured by BIOS directly into CRTM, and we could 
> immediately follow DRTM from here...
> And I could maybe sign the tboot binary for Secure Boot instead of using 
> poorly-documented GRUB :-)
> 
> Thanks
> 
> Jan
> 
> 
> 
> --
> Find and fix application performance issues faster with Applications Manager 
> Applications Manager provides deep performance insights into multiple tiers 
> of your business applications. It resolves application problems quickly and 
> reduces your MTTR. Get your free trial!
> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> ___
> tboot-devel mailing list
> tboot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/tboot-devel


--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights in