tboot-devel — Developer support

Re: [tboot-devel] [Tboot-changelog] changeset in tboot.hg: Fixed bug in creation of LCP_PCONF_ELEMENT

[Michael G. <m.g...@tu...>]

Hello!

Joseph Cihula wrote:
> changeset 57ea1beb3bc8 in /var/www/tboot.hg
> details: tboot.hg?cmd=changeset;node=57ea1beb3bc8
> description:
> 	Fixed bug in creation of LCP_PCONF_ELEMENT

That fix doesn't compile on debian lenny since it uses glibc 2.7, and the macros htobe32() and 
friends were introduced in glibc 2.9 AFAIK (yeah, I know, lenny is far too old, but hey, it's debian 
stable...)

Michael

Re: [tboot-devel] GETSEC[SENTER] fail on HP dc7800

[Jonathan M. <jon...@cm...>]

On Thu, Jul 22, 2010 at 9:28 PM, Cihula, Joseph <jos...@in...> wrote:
> The possible culprits for a change in behavior could be:  "significant" memory change (e.g. <4GB to >4GB, PCI/PCIe devices added/removed, internal devices enabled/disabled (e.g. Azalia, ME).  You could also try resetting the BIOS to its defaults.

Hmm, it has 4GB of RAM in two 2GB DIMMs, which it has always had.

I tried having a NIC in each of the 3 PCIe slots one at a time.  There
has always been a 1394 (firewire) adapter in the system's sole PCI
slot.  I tried removing it anyways.  None of this affected anything.
Same two error codes.  v16, v17, v18 of the SINIT all appear to behave
identically.  I've been favoring the 20090330 version of tboot.

I did reset the BIOS to factory defaults.  Again, no apparent change.
I've reverted to BIOS v1.27 since that's what I've had on the system
for most of its life.

Hal, if you're out there, what is the BIOS version, memory config, PCI
/ PCIe config, BIOS settings of your dc7800 (or anybody else who has
one that is working)?  Perhaps a photo of the system with its lid off?

Thanks for any ideas,
-Jon

Re: [tboot-devel] GETSEC[SENTER] fail on HP dc7800

[Cihula, J. <jos...@in...>]

> From: Jonathan McCune [mailto:jon...@cm...]
> Sent: Thursday, July 22, 2010 4:01 PM
> 
> Well, I tried lots of BIOS versions.  v1.24 gives me a Microcode Error
> 1801 (unrelated to TXT) and runs the fans at full speed, so I didn't
> get very far with it.  v1.26 hangs with the BIOS screen displayed
> after rebooting immediately upon executing SENTER (again sounds
> consistent with what Hal was reporting with his 'older' BIOS -- I'm
> guessing that was v1.26).  v1.28's behavior is indistinguishable from
> that of v1.27's, which was the version that has been on my machine for
> months or possibly years.
> 
> I tried disabling basically everything non-essential in BIOS (left
> enabled a single serial port, single SATA port, Ethernet, and video;
> disabled USB, firewire, parallel port, floppy, CD-ROM, audio, ...).
> No change.  Just toggles between the two TXT.ERRORCODES (0xC00020A1 or
> 0xC00018A1).
> 
> This really has me confused.  I've successfully used this machine for
> tboot/Flicker countless times in the past, and I really have no idea
> what would have changed that suddenly caused it to behave the way Hal
> previously described things.
> 
> Could adding or removing PCI cards make a difference?  It may have
> previously had two NICs, and now only has one (can't remember for
> sure).
> 
> It has 4GB of RAM, which I believe it has always had.  I can always
> try removing some...
> 
> Any ideas?

The possible culprits for a change in behavior could be:  "significant" memory change (e.g. <4GB to >4GB, PCI/PCIe devices added/removed, internal devices enabled/disabled (e.g. Azalia, ME).  You could also try resetting the BIOS to its defaults.

Joe

> 
> Thanks,
> -Jon
> 
> 
> 
> On Thu, Jul 22, 2010 at 5:02 PM, Jonathan McCune <jon...@cm...> wrote:
> > Hi Hal, Martin, list,
> >
> > Any progress on this front?  I've just run into this same issue (error
> > codes 0xC00020A1 or 0xC00018A1 depending on whether USB/floppy/1394
> > are enabled -- suspect USB is what's meaningful but haven't dissected
> > it) on a dc7800 with tboot-20100427 (w/ Q35 SINIT modules v18, 17,and
> > 16) and tboot-20090330 (w/ Q35 SINIT module v16).  I hope to continue
> > experimenting with interesting combinations, but when I last used this
> > machine, I don't recall ever having this problem.
> >
> > My system has BIOS version 1.27 installed.  I can see that there's a
> > 1.28 available from HP's web page.  Hal, you said that reverting BIOS
> > versions helped you out.  Do you happen to know which version you
> > used?  If it's younger than 1.27, do you happen to have the installer
> > for it?
> >
> > I'll post a follow-up if I figure out anything interesting.
> >
> > Thanks,
> > -Jon
> >
> >
> > On Sat, Aug 1, 2009 at 6:54 AM, Martin Thiim <ma...@th...> wrote:
> >> Hi
> >>
> >> Great. However, I'm still curious about what caused it to fail. I hope
> >> in the future more info will be released on what SINIT actually does.
> >>
> >> As my last posts indicated, it probably isn't/wasn't an inconsistency
> >> in the tables themselves, but rather an inconsistency with the tables
> >> and something outside the tables, such as either the PCI device BAR
> >> registers, or perhaps the register base of the DMA units that are off
> >> (i.e. maybe these registers don't actually point to a DMA unit).
> >>
> >> Best regards,
> >>
> >> Martin Thiim
> >>
> >> On Sat, Aug 1, 2009 at 8:40 AM, Hal Finney<hal...@gm...> wrote:
> >>> As an update, I successfully rolled back my BIOS to an earlier
> >>> version. With this change, tboot works again! GETSEC[SENTER] executes
> >>> with no errors and I get into the secure state. So it is definitely
> >>> some problem relating to the new BIOS.
> >>>
> >>> Interestingly, I dumped the DMAR tables created by the working BIOS
> >>> and they are byte for byte identical to what they were with the
> >>> non-working BIOS. So clearly there is no point in going over those
> >>> tables with a fine tooth comb to figure out what SINIT doesn't like
> >>> about them. Something else must be different. I'd say the SINIT error
> >>> codes are not particularly informative about what is going wrong in
> >>> this case.
> >>>
> >>> I hope the SINIT team will still look into this. I can easily go back
> >>> to the newer BIOS in order to reproduce the failing state. The new
> >>> BIOS has the advantage that I can reboot after an SINIT failure and
> >>> read the errorcode register. With the old BIOS, attempts to reboot
> >>> hang in the BIOS and it's not possible to read the errorcodes, which
> >>> made debugging TXT almost impossible.
> >>>
> >>> So I can either use the new BIOS which would allow some debugging but
> >>> which unfortunately doesn't work with SINIT; or I can use the old BIOS
> >>> which works with SINIT but reveals nothing when there is a failure.
> >>> Neither is a great alternative.
> >>>
> >>> Hal Finney
> >>>
> >>
> >> ------------------------------------------------------------------------------
> >> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> >> trial. Simplify your report design, integration and deployment - and focus on
> >> what you do best, core application coding. Discover what's new with
> >> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> >> _______________________________________________
> >> tboot-devel mailing list
> >> tbo...@li...
> >> https://lists.sourceforge.net/lists/listinfo/tboot-devel
> >>
> >>
> >
> 
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> tboot-devel mailing list
> tbo...@li...
> https://lists.sourceforge.net/lists/listinfo/tboot-devel

Re: [tboot-devel] GETSEC[SENTER] fail on HP dc7800

[Jonathan M. <jon...@cm...>]

Well, I tried lots of BIOS versions.  v1.24 gives me a Microcode Error
1801 (unrelated to TXT) and runs the fans at full speed, so I didn't
get very far with it.  v1.26 hangs with the BIOS screen displayed
after rebooting immediately upon executing SENTER (again sounds
consistent with what Hal was reporting with his 'older' BIOS -- I'm
guessing that was v1.26).  v1.28's behavior is indistinguishable from
that of v1.27's, which was the version that has been on my machine for
months or possibly years.

I tried disabling basically everything non-essential in BIOS (left
enabled a single serial port, single SATA port, Ethernet, and video;
disabled USB, firewire, parallel port, floppy, CD-ROM, audio, ...).
No change.  Just toggles between the two TXT.ERRORCODES (0xC00020A1 or
0xC00018A1).

This really has me confused.  I've successfully used this machine for
tboot/Flicker countless times in the past, and I really have no idea
what would have changed that suddenly caused it to behave the way Hal
previously described things.

Could adding or removing PCI cards make a difference?  It may have
previously had two NICs, and now only has one (can't remember for
sure).

It has 4GB of RAM, which I believe it has always had.  I can always
try removing some...

Any ideas?

Thanks,
-Jon



On Thu, Jul 22, 2010 at 5:02 PM, Jonathan McCune <jon...@cm...> wrote:
> Hi Hal, Martin, list,
>
> Any progress on this front?  I've just run into this same issue (error
> codes 0xC00020A1 or 0xC00018A1 depending on whether USB/floppy/1394
> are enabled -- suspect USB is what's meaningful but haven't dissected
> it) on a dc7800 with tboot-20100427 (w/ Q35 SINIT modules v18, 17,and
> 16) and tboot-20090330 (w/ Q35 SINIT module v16).  I hope to continue
> experimenting with interesting combinations, but when I last used this
> machine, I don't recall ever having this problem.
>
> My system has BIOS version 1.27 installed.  I can see that there's a
> 1.28 available from HP's web page.  Hal, you said that reverting BIOS
> versions helped you out.  Do you happen to know which version you
> used?  If it's younger than 1.27, do you happen to have the installer
> for it?
>
> I'll post a follow-up if I figure out anything interesting.
>
> Thanks,
> -Jon
>
>
> On Sat, Aug 1, 2009 at 6:54 AM, Martin Thiim <ma...@th...> wrote:
>> Hi
>>
>> Great. However, I'm still curious about what caused it to fail. I hope
>> in the future more info will be released on what SINIT actually does.
>>
>> As my last posts indicated, it probably isn't/wasn't an inconsistency
>> in the tables themselves, but rather an inconsistency with the tables
>> and something outside the tables, such as either the PCI device BAR
>> registers, or perhaps the register base of the DMA units that are off
>> (i.e. maybe these registers don't actually point to a DMA unit).
>>
>> Best regards,
>>
>> Martin Thiim
>>
>> On Sat, Aug 1, 2009 at 8:40 AM, Hal Finney<hal...@gm...> wrote:
>>> As an update, I successfully rolled back my BIOS to an earlier
>>> version. With this change, tboot works again! GETSEC[SENTER] executes
>>> with no errors and I get into the secure state. So it is definitely
>>> some problem relating to the new BIOS.
>>>
>>> Interestingly, I dumped the DMAR tables created by the working BIOS
>>> and they are byte for byte identical to what they were with the
>>> non-working BIOS. So clearly there is no point in going over those
>>> tables with a fine tooth comb to figure out what SINIT doesn't like
>>> about them. Something else must be different. I'd say the SINIT error
>>> codes are not particularly informative about what is going wrong in
>>> this case.
>>>
>>> I hope the SINIT team will still look into this. I can easily go back
>>> to the newer BIOS in order to reproduce the failing state. The new
>>> BIOS has the advantage that I can reboot after an SINIT failure and
>>> read the errorcode register. With the old BIOS, attempts to reboot
>>> hang in the BIOS and it's not possible to read the errorcodes, which
>>> made debugging TXT almost impossible.
>>>
>>> So I can either use the new BIOS which would allow some debugging but
>>> which unfortunately doesn't work with SINIT; or I can use the old BIOS
>>> which works with SINIT but reveals nothing when there is a failure.
>>> Neither is a great alternative.
>>>
>>> Hal Finney
>>>
>>
>> ------------------------------------------------------------------------------
>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
>> trial. Simplify your report design, integration and deployment - and focus on
>> what you do best, core application coding. Discover what's new with
>> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>> _______________________________________________
>> tboot-devel mailing list
>> tbo...@li...
>> https://lists.sourceforge.net/lists/listinfo/tboot-devel
>>
>>
>

Re: [tboot-devel] GETSEC[SENTER] fail on HP dc7800

[Jonathan M. <jon...@cm...>]

Hi Hal, Martin, list,

Any progress on this front?  I've just run into this same issue (error
codes 0xC00020A1 or 0xC00018A1 depending on whether USB/floppy/1394
are enabled -- suspect USB is what's meaningful but haven't dissected
it) on a dc7800 with tboot-20100427 (w/ Q35 SINIT modules v18, 17,and
16) and tboot-20090330 (w/ Q35 SINIT module v16).  I hope to continue
experimenting with interesting combinations, but when I last used this
machine, I don't recall ever having this problem.

My system has BIOS version 1.27 installed.  I can see that there's a
1.28 available from HP's web page.  Hal, you said that reverting BIOS
versions helped you out.  Do you happen to know which version you
used?  If it's younger than 1.27, do you happen to have the installer
for it?

I'll post a follow-up if I figure out anything interesting.

Thanks,
-Jon


On Sat, Aug 1, 2009 at 6:54 AM, Martin Thiim <ma...@th...> wrote:
> Hi
>
> Great. However, I'm still curious about what caused it to fail. I hope
> in the future more info will be released on what SINIT actually does.
>
> As my last posts indicated, it probably isn't/wasn't an inconsistency
> in the tables themselves, but rather an inconsistency with the tables
> and something outside the tables, such as either the PCI device BAR
> registers, or perhaps the register base of the DMA units that are off
> (i.e. maybe these registers don't actually point to a DMA unit).
>
> Best regards,
>
> Martin Thiim
>
> On Sat, Aug 1, 2009 at 8:40 AM, Hal Finney<hal...@gm...> wrote:
>> As an update, I successfully rolled back my BIOS to an earlier
>> version. With this change, tboot works again! GETSEC[SENTER] executes
>> with no errors and I get into the secure state. So it is definitely
>> some problem relating to the new BIOS.
>>
>> Interestingly, I dumped the DMAR tables created by the working BIOS
>> and they are byte for byte identical to what they were with the
>> non-working BIOS. So clearly there is no point in going over those
>> tables with a fine tooth comb to figure out what SINIT doesn't like
>> about them. Something else must be different. I'd say the SINIT error
>> codes are not particularly informative about what is going wrong in
>> this case.
>>
>> I hope the SINIT team will still look into this. I can easily go back
>> to the newer BIOS in order to reproduce the failing state. The new
>> BIOS has the advantage that I can reboot after an SINIT failure and
>> read the errorcode register. With the old BIOS, attempts to reboot
>> hang in the BIOS and it's not possible to read the errorcodes, which
>> made debugging TXT almost impossible.
>>
>> So I can either use the new BIOS which would allow some debugging but
>> which unfortunately doesn't work with SINIT; or I can use the old BIOS
>> which works with SINIT but reveals nothing when there is a failure.
>> Neither is a great alternative.
>>
>> Hal Finney
>>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> tboot-devel mailing list
> tbo...@li...
> https://lists.sourceforge.net/lists/listinfo/tboot-devel
>
>

Re: [tboot-devel] Incorrect command line handling with GRUB 1.97 and above

[Michael G. <m.g...@tu...>]

Hi!

I forgot to mention that the initialization of g_log_targets in printk.c is pointless. g_log_targets 
is always overwritten by get_tboot_log_targets() because get_option_val() will return "serial" if 
logging isn't specified via command line.

I suggest to remove "serial" from g_tboot_cmdline_options[] in cmdline.c
(see attached diff)

Michael

Re: [tboot-devel] Help: error code 0xc0000c71

[Cihula, J. <jos...@in...>]

Can you dump your page tables (pdpt/pdt/pt) and send that?

Joe

From: 陈进 [mailto:cic...@gm...]
Sent: Friday, July 16, 2010 1:55 AM
To: tbo...@li...
Subject: [tboot-devel] Help: error code 0xc0000c71

I'm trying to enter MLE after xen bootup, but get a error code 0xc0000c71 now.
I use the Q45_Q43_SINIT_19.BIN as AC module, and the error file says the error is a non-initial entry (PDPE/PDE/PTE) is invalid/not present (i.e. holes in page table are not allowed)

I put the MLE page table at 0xbec0000, the first 3 pages are the PDPT, PDT, PT, and the MLE code is at 0xbec3000, its size is about 38 pages.

I can't find any question, where is bug?

--
There's nothing either good or bad , but thinking makes it so.

[tboot-devel] Help: error code 0xc0000c71

[陈进 <cic...@gm...>]

I'm trying to enter MLE after xen bootup, but get a error code 0xc0000c71
now.
I use the Q45_Q43_SINIT_19.BIN as AC module, and the error file says the
error is *a non-initial entry (PDPE/PDE/PTE) is invalid/not present** **(i.e.
holes in page table are not allowed)*
*
*
I put the MLE page table at 0xbec0000, the first 3 pages are the PDPT, PDT,
PT, and the MLE code is at 0xbec3000, its size is about 38 pages.

I can't find any question, where is bug?

-- 
There's nothing either good or bad , but thinking makes it so.

Re: [tboot-devel] [PATCH] fix some build issues

[Michael G. <m.g...@tu...>]

Cihula, Joseph wrote:
> Thank you very much for the patches and we should be applying them very shortly.  But we need you to add Signed-off-by: lines to each of them before we can apply them.

Hm, adding a message to a diff file could get difficult. But feel free to add my signed-off manually 
when committing to your repo.

Signed-off-by: Michael Gissing <m.g...@tu...>

It would be helpful if you would provide information about how you want patches to be sent. I don't 
know how to create a proper patch file using mercurial.

> Joe

Michael

Re: [tboot-devel] [PATCH] fix some build issues

[Cihula, J. <jos...@in...>]

> From: Michael Gissing [mailto:m.g...@tu...]
> Sent: Thursday, July 15, 2010 4:25 AM
> 
> Hi!
> 
> Find 3 patches attached.
> 
> *) fix_missing_defines.patch
> The freshly cloned repo doesn't compile without these defines.
> 
> *) fix_strncat_usage.patch
> Resolves the issue pointed out by Martin Pirker (26 Apr 2010 14:36).
> 
> *) fix_off_by_one.patch
> Assignment is always out of bounds.

Thank you very much for the patches and we should be applying them very shortly.  But we need you to add Signed-off-by: lines to each of them before we can apply them.

Joe

[tboot-devel] [PATCH] fix some build issues

[Michael G. <m.g...@tu...>]

Hi!

Find 3 patches attached.

*) fix_missing_defines.patch
The freshly cloned repo doesn't compile without these defines.

*) fix_strncat_usage.patch
Resolves the issue pointed out by Martin Pirker (26 Apr 2010 14:36).

*) fix_off_by_one.patch
Assignment is always out of bounds.

Michael

[tboot-devel] Incorrect command line handling with GRUB 1.97 and above

[Michael G. <m.g...@tu...>]

Hi!

GRUB2 changed its behavior on how to deal with command lines[1] starting with version 1.97. There's
also a debian bug[2] filed.

GRUB2 now discards the first element (the filename) before storing the command line in mbi->cmdline.
Since TBoot always calls skip_filename(), g_cmdline loses first element of command line... It took
me hours to figure out that this was the reason why I don't get any output from TBoot.

A possible solution could be parsing of mbi->boot_loader_name, that can be tricky...

The workaround suggested by GRUB developers is to specify the filename a second time. As the
filename isn't relevant to TBoot, any dummy argument can be stated.

Michael

[1] http://www.mail-archive.com/gru...@gn.../msg11801.html
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=557645

[tboot-devel] i7 quad SINIT posted

[Cihula, J. <jos...@in...>]

The SINIT ACM for the Intel(R) Core(TM) i7-800 Desktop Processor Series, i7-900 Mobile Processor Extreme Edition Series, i7-800 & i7-700 Mobile Processor Series (Lynnfield & Clarksfield) has been posted to the tboot SourceForge site.

As with the i5/i7 dual SINIT ACM, these are based on the processor rather than the chipset.

Joe

Re: [tboot-devel] Problem in desktop display with TBOOT & Custom Kernel (FC13)

[Satish K. <sat...@gm...>]

Hi,

Symptoms - When i boot the system using new kernel and tboot, I am not able
to see my desktop/display. It shows lines/boxes. You can not see anything at
all. When it boots i can see TBOOT: messages after the boot process, nothing
is coming up. So i can not do anything, just need to hard boot the system.

The last two boot options of my grub.conf do not work and having problems as
described above. System is sierra, and original kernel is 2.6.33.1-24 FC13.

T kernel source which i used to build my own kernel is 2.6.33.4-95 which is
newer than my original. Do you think it should matter? Because when i
executed 'yumdownloader --source kernel' i got this version of kernel.

Please let me know.

Thanks,
Satish.

On Thu, May 20, 2010 at 5:30 PM, Corrion, Bradley W <
bra...@in...> wrote:

>  Hi Satish,
>
>
>
> Nice to meet you.  For the most part you should have success booting any
> kernel from tboot, with or without TXT.  Obviously if the kernel doesn’t
> have TXT explicitly enabled, the benefits won’t be present, but the kernel
> will still boot.
>
>
>
> Nothing jumped out at me from the grub options in this entry:
>
>
>
> title TBOOT Fedora (SK.fc13.i686)
>
>     root (hd0,0)
>
>     kernel /boot/tboot.gz logging=serial,vga,memory
>
>     module /boot/vmlinuz-2.6.33.4-95.SK.fc13.i686 ro
> root=UUID=e5dd1252-13a8-4516-b44d-52e6ee335f36 rd_NO_LUKS rd_NO_LVM rd_NO_MD
> rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=us rhgb
> tpm_tis.force=1 tpm_tis.itpm=1 tpm_tis.interrupts=0 intel_iommu=on
>
>     module /boot/initramfs-2.6.33.4-95.SK.fc13.i686.img
>
>     module /boot/Q45_Q43_SINIT_19.BIN
>
>
>
> But what are the symptoms you are seeing?  And is the difference simply
> invoking TBOOT or not invoking TBOOT on the same kernel?
>
>
>
> Thanks,
>
> Brad
>
>
>
> *Brad Corrion*
>
> Platform Architect
>
> Embedded & Communications Group
>
> 480-552-3366
>
>
>
> *From:* Satish Kagathara [mailto:sat...@gm...]
> *Sent:* Thursday, May 20, 2010 10:35 AM
> *To:* Corrion, Bradley W
> *Subject:* Re: [tboot-devel] Problem in desktop display with TBOOT &
> Custom Kernel (FC13)
>
>
>
> Hi Brad,
>
> Thank you for prompt response. Yes you are right. I am working with team in
> Diebold and referred FC tutorial. I have been trying to identify & resolve
> this problem from last 3 days but could not. Then i updated softwares on
> original kernel using Software Updates to see whether it resolves the
> problem or not. With the software updates i see another kernel-2.6.33.3-85
> added to my grub.conf and i was able to up the system with that too.
>
> Finally i ended up with different options in my grub.conf (few
> automatically added by installing kernel) to verify which all works. I have
> copied grub.conf and some other info for your reference.
>
> I have added my initials "SK" to custom kernel.
>
> If i run "rpm -qa | grep kernel", i can see following result -
> kernel-PAE-devel-2.6.33.1-24.fc13.i686
> kernel-PAE-2.6.33.1-24.fc13.i686
> kernel-headers-2.6.33.4-95.SK.fc13.i686
> kernel-PAE-2.6.33.3-85.fc13.i686
> kernel-PAE-devel-2.6.33.3-85.fc13.i686
> abrt-addon-kerneloops-1.1.0-1.fc13.i686
> kernel-PAE-2.6.33.4-95.SK.fc13.i686
> kernel-headers-2.6.33.3-85.fc13.i686
> kernel-2.6.33.4-95.SK.fc13.i686
> kernel-PAE-devel-2.6.33.4-95.SK.fc13.i686
>
> Versions of -
> tpm-tools-1.3.5-2.fc13.i686
> trousers-devel-0.3.4-2.fc13.i686
> trousers-0.3.4-2.fc13.i686
>
> grub.conf
> -----------------------------------------------------------------------
> # grub.conf generated by anaconda
> #
> # Note that you do not have to rerun grub after making changes to this file
> # NOTICE:  You do not have a /boot partition.  This means that
> #          all kernel and initrd paths are relative to /, eg.
> #          root (hd0,0)
> #          kernel /boot/vmlinuz-version ro root=/dev/sda1
> #          initrd /boot/initrd-[generic-]version.img
> #boot=/dev/sda
> default=6
> timeout=6
> splashimage=(hd0,0)/boot/grub/splash.xpm.gz
> hiddenmenu
>
> title Fedora (2.6.33.1-24.fc13.i686.PAE)
>     root (hd0,0)
>     kernel /boot/vmlinuz-2.6.33.1-24.fc13.i686.PAE ro
> root=UUID=e5dd1252-13a8-4516-b44d-52e6ee335f36 rd_NO_LUKS rd_NO_LVM rd_NO_MD
> rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=us rhgb
> tpm_tis.force=1 tpm_tis.itpm=1 tpm_tis.interrupts=0
>     initrd /boot/initramfs-2.6.33.1-24.fc13.i686.PAE.img
>
> title Fedora (2.6.33.3-85.fc13.i686.PAE)
>     root (hd0,0)
>     kernel /boot/vmlinuz-2.6.33.3-85.fc13.i686.PAE ro
> root=UUID=e5dd1252-13a8-4516-b44d-52e6ee335f36 rd_NO_LUKS rd_NO_LVM rd_NO_MD
> rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=us rhgb
> tpm_tis.force=1 tpm_tis.itpm=1 tpm_tis.interrupts=0
>     initrd /boot/initramfs-2.6.33.3-85.fc13.i686.PAE.img
>
> title Fedora (2.6.33.4-95.SK.fc13.i686)
>     root (hd0,0)
>     kernel /boot/vmlinuz-2.6.33.4-95.SK.fc13.i686 ro
> root=UUID=e5dd1252-13a8-4516-b44d-52e6ee335f36 rd_NO_LUKS rd_NO_LVM rd_NO_MD
> rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=us rhgb
> tpm_tis.force=1 tpm_tis.itpm=1 tpm_tis.interrupts=0
>     initrd /boot/initramfs-2.6.33.4-95.SK.fc13.i686.img
>
> title Fedora (2.6.33.4-95.SK.fc13.i686.PAE)
>     root (hd0,0)
>     kernel /boot/vmlinuz-2.6.33.4-95.SK.fc13.i686.PAE ro
> root=UUID=e5dd1252-13a8-4516-b44d-52e6ee335f36 rd_NO_LUKS rd_NO_LVM rd_NO_MD
> rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=us rhgb
> tpm_tis.force=1 tpm_tis.itpm=1 tpm_tis.interrupts=0
>     initrd /boot/initramfs-2.6.33.4-95.SK.fc13.i686.PAE.img
>
> title TBOOT Fedora (Original)
>     root (hd0,0)
>     kernel /boot/tboot.gz logging=serial,vga,memory
>     module /boot/vmlinuz-2.6.33.1-24.fc13.i686.PAE ro
> root=UUID=e5dd1252-13a8-4516-b44d-52e6ee335f36 rd_NO_LUKS rd_NO_LVM rd_NO_MD
> rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=us rhgb
> tpm_tis.force=1 tpm_tis.itpm=1 tpm_tis.interrupts=0 intel_iommu=on
>     module /boot/initramfs-2.6.33.1-24.fc13.i686.PAE.img
>     module /boot/Q45_Q43_SINIT_19.BIN
>
> title TBOOT Fedora (Updated)
>     root (hd0,0)
>     kernel /boot/tboot.gz logging=serial,vga,memory
>     module /boot/vmlinuz-2.6.33.3-85.fc13.i686.PAE ro
> root=UUID=e5dd1252-13a8-4516-b44d-52e6ee335f36 rd_NO_LUKS rd_NO_LVM rd_NO_MD
> rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=us rhgb
> tpm_tis.force=1 tpm_tis.itpm=1 tpm_tis.interrupts=0 intel_iommu=on
>     module /boot/initramfs-2.6.33.3-85.fc13.i686.PAE.img
>     module /boot/Q45_Q43_SINIT_19.BIN
>
> title TBOOT Fedora (SK.fc13.i686)
>     root (hd0,0)
>     kernel /boot/tboot.gz logging=serial,vga,memory
>     module /boot/vmlinuz-2.6.33.4-95.SK.fc13.i686 ro
> root=UUID=e5dd1252-13a8-4516-b44d-52e6ee335f36 rd_NO_LUKS rd_NO_LVM rd_NO_MD
> rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=us rhgb
> tpm_tis.force=1 tpm_tis.itpm=1 tpm_tis.interrupts=0 intel_iommu=on
>     module /boot/initramfs-2.6.33.4-95.SK.fc13.i686.img
>     module /boot/Q45_Q43_SINIT_19.BIN
>
> title TBOOT Fedora (SK.fc13.i686.PAE)
>     root (hd0,0)
>     kernel /boot/tboot.gz logging=serial,vga,memory
>     module /boot/vmlinuz-2.6.33.4-95.SK.fc13.i686.PAE ro
> root=UUID=e5dd1252-13a8-4516-b44d-52e6ee335f36 rd_NO_LUKS rd_NO_LVM rd_NO_MD
> rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=us rhgb
> tpm_tis.force=1 tpm_tis.itpm=1 tpm_tis.interrupts=0 intel_iommu=on
>     module /boot/initramfs-2.6.33.4-95.SK.fc13.i686.PAE.img
>     module /boot/Q45_Q43_SINIT_19.BIN
> #
>
> ---------------------------------------------------------------------------------
>
> Currently i am in Canton, OH. My contact no - 330 498 2754
>
> Thanks,
> Satish.
>
> On Thu, May 20, 2010 at 12:43 PM, Corrion, Bradley W <
> bra...@in...> wrote:
>
> Hi Satish,
>
>
>
> Are you working with the team in Akron, too (are you using the FC tutorial
> I provided them)?  Would you be able to share your grub.conf with me?
>
>
>
> Thanks
>
> Brad
>
>
>
> *Brad Corrion*
>
> Platform Architect
>
> Embedded & Communications Group
>
> 480-552-3366
>
>
>
> *From:* Satish Kagathara [mailto:sat...@gm...]
> *Sent:* Thursday, May 20, 2010 8:52 AM
> *To:* tbo...@li...; Cihula, Joseph
> *Subject:* [tboot-devel] Problem in desktop display with TBOOT & Custom
> Kernel (FC13)
>
>
>
>
>
> Hello,
>
> I have rebuild custom kernel by just enabling Intel Trusted Exceution
> Technology option under Security configuration option. After that i am
> trying to boot the system using kernel tboot, SINIT for trusted boot using
> this newly build kernel. It boots properly and shows TBOOT messages during
> boot but it does not shows proper desktop/display. It shows some square
> boxes/lines on my display. Cursor is square box which i was able to move it.
>
>
> Original kernel - 2.6.33.1-24.fc13.i686
> Custom kernel - 2.6.33.4-95.SK.fc13.i686
>
> I built custom kernel using rpmbuild -bp --target=i686 kernel.spec (build
> all kernel flavors). Link -
> http://fedoraproject.org/wiki/Docs/CustomKernel
>
> Please note that i am facing this problem when i boot with tboot. If i boot
> using custom kernel which i built without tboot it works fine.
> Display/desktop is proper. So i am not able to figure out where exactly the
> problem is? Also, i am able to boot properly with tboot and my original
> kernel (2.6.33.1-24) and desktop is also coming up properly.
>
> Can you please provide any help to resolve this issue? I had installed
> tpm-tools, trousers trousers-devel, tboot.gz, modified grub.conf
> accordingly.
>
> I started the system with my original kernel and was getting below error
> messages in Automatic Bug Reporting Tool.
>
>
> WARNING: at mm/highmem.c:444 debug_kmap_atomic+0xad/0x12a()
> Hardware name: Sierra
> Modules linked in: tpm_infineon ipv6 uinput snd_hda_codec_analog
> snd_hda_intel snd_hda_codec e1000e snd_hwdep i2c_i801 snd_seq iTCO_wdt
> iTCO_vendor_support snd_seq_device snd_pcm snd_timer snd soundcore serio_raw
> snd_page_alloc microcode dm_multipath pata_acpi ata_generic i915
> drm_kms_helper drm i2c_algo_bit i2c_core video output [last unloaded:
> scsi_wait_scan]
> Pid: 0, comm: swapper Tainted: G        W  2.6.33.4-95.SK.fc13.i686 #1
> Call Trace:
> [<c0c36e2d>] warn_slowpath_common+0x65/0x7c
> [<c0caa681>] ? debug_kmap_atomic+0xad/0x12a
> [<c0c36e51>] warn_slowpath_null+0xd/0x10
> [<c0caa681>] debug_kmap_atomic+0xad/0x12a
> [<c0c240a4>] kmap_atomic_prot+0x51/0xd2
> [<f7ff5f4d>] ? i915_error_object_create+0x5d/0xfa [i915]
> [<c0c24133>] kmap_atomic+0xe/0x10
> [<f7ff5f8f>] i915_error_object_create+0x9f/0xfa [i915]
> [<f7ff631a>] i915_handle_error+0x330/0x813 [i915]
> [<f7ff69a3>] i915_driver_irq_handler+0xc7/0x2f4 [i915]
> [<c0c504a3>] ? sched_clock_local+0x17/0x11e
> [<c0c78fb4>] handle_IRQ_event+0x52/0xf8
> [<c0c7a74a>] handle_edge_irq+0xc7/0x10b
> [<c0c04cd3>] handle_irq+0x3b/0x48
> [<c0c04558>] do_IRQ+0x41/0x9a
> [<c0c03830>] common_interrupt+0x30/0x38
> [<c0c5007b>] ? update_target+0x4/0xc0
> [<c0df52c9>] ? acpi_idle_enter_bm+0x251/0x282
> [<c0ec78b6>] cpuidle_idle_call+0x6d/0xbf
> [<c0c024b8>] cpu_idle+0x91/0xad
> [<c0f5e59e>] rest_init+0x62/0x64
> [<c11b78f1>] start_kernel+0x346/0x34b
> [<c11b7099>] i386_start_kernel+0x99/0xa0
>
>
>
>



-- 
Thanks & Regards,
Satish Kagathara.
Team Lead,
Diebold Software Services Pvt. Ltd.
Mumbai, India.

E-Mail: sat...@gm...
Phone: +91-22-66497573(O) / +91-98693 95421(Mobile)

Re: [tboot-devel] Problem in desktop display with TBOOT & Custom Kernel (FC13)

[Cihula, J. <jos...@in...>]

What system is this?

Joe

From: Satish Kagathara [mailto:sat...@gm...]
Sent: Thursday, May 20, 2010 8:52 AM
To: tbo...@li...; Cihula, Joseph
Subject: Problem in desktop display with TBOOT & Custom Kernel (FC13)


Hello,

I have rebuild custom kernel by just enabling Intel Trusted Exceution Technology option under Security configuration option. After that i am trying to boot the system using kernel tboot, SINIT for trusted boot using this newly build kernel. It boots properly and shows TBOOT messages during boot but it does not shows proper desktop/display. It shows some square boxes/lines on my display. Cursor is square box which i was able to move it.

Original kernel - 2.6.33.1-24.fc13.i686
Custom kernel - 2.6.33.4-95.SK.fc13.i686

I built custom kernel using rpmbuild -bp --target=i686 kernel.spec (build all kernel flavors). Link - http://fedoraproject.org/wiki/Docs/CustomKernel

Please note that i am facing this problem when i boot with tboot. If i boot using custom kernel which i built without tboot it works fine. Display/desktop is proper. So i am not able to figure out where exactly the problem is? Also, i am able to boot properly with tboot and my original kernel (2.6.33.1-24) and desktop is also coming up properly.

Can you please provide any help to resolve this issue? I had installed tpm-tools, trousers trousers-devel, tboot.gz, modified grub.conf accordingly.

I started the system with my original kernel and was getting below error messages in Automatic Bug Reporting Tool.


WARNING: at mm/highmem.c:444 debug_kmap_atomic+0xad/0x12a()
Hardware name: Sierra
Modules linked in: tpm_infineon ipv6 uinput snd_hda_codec_analog snd_hda_intel snd_hda_codec e1000e snd_hwdep i2c_i801 snd_seq iTCO_wdt iTCO_vendor_support snd_seq_device snd_pcm snd_timer snd soundcore serio_raw snd_page_alloc microcode dm_multipath pata_acpi ata_generic i915 drm_kms_helper drm i2c_algo_bit i2c_core video output [last unloaded: scsi_wait_scan]
Pid: 0, comm: swapper Tainted: G        W  2.6.33.4-95.SK.fc13.i686 #1
Call Trace:
[<c0c36e2d>] warn_slowpath_common+0x65/0x7c
[<c0caa681>] ? debug_kmap_atomic+0xad/0x12a
[<c0c36e51>] warn_slowpath_null+0xd/0x10
[<c0caa681>] debug_kmap_atomic+0xad/0x12a
[<c0c240a4>] kmap_atomic_prot+0x51/0xd2
[<f7ff5f4d>] ? i915_error_object_create+0x5d/0xfa [i915]
[<c0c24133>] kmap_atomic+0xe/0x10
[<f7ff5f8f>] i915_error_object_create+0x9f/0xfa [i915]
[<f7ff631a>] i915_handle_error+0x330/0x813 [i915]
[<f7ff69a3>] i915_driver_irq_handler+0xc7/0x2f4 [i915]
[<c0c504a3>] ? sched_clock_local+0x17/0x11e
[<c0c78fb4>] handle_IRQ_event+0x52/0xf8
[<c0c7a74a>] handle_edge_irq+0xc7/0x10b
[<c0c04cd3>] handle_irq+0x3b/0x48
[<c0c04558>] do_IRQ+0x41/0x9a
[<c0c03830>] common_interrupt+0x30/0x38
[<c0c5007b>] ? update_target+0x4/0xc0
[<c0df52c9>] ? acpi_idle_enter_bm+0x251/0x282
[<c0ec78b6>] cpuidle_idle_call+0x6d/0xbf
[<c0c024b8>] cpu_idle+0x91/0xad
[<c0f5e59e>] rest_init+0x62/0x64
[<c11b78f1>] start_kernel+0x346/0x34b
[<c11b7099>] i386_start_kernel+0x99/0xa0



--
Thanks & Regards,
Satish Kagathara.
Team Lead,
Diebold Software Services Pvt. Ltd.
Mumbai, India.

E-Mail: sat...@gm...<mailto:sat...@gm...>
Phone: +91-22-66497573(O) / +91-98693 95421(Mobile)

Re: [tboot-devel] TBoot+Intel DQ45CB, update

[Corrion, B. W <bra...@in...>]

I too was able to verify the fix on my DQ45CB board.  

Thanks!
Brad

Brad Corrion
Platform Architect
Embedded & Communications Group
480-552-3366


-----Original Message-----
From: Martin Pirker [mailto:Mar...@ia...] 
Sent: Thursday, May 20, 2010 7:52 AM
To: Cihula, Joseph
Cc: tbo...@li...
Subject: Re: [tboot-devel] TBoot+Intel DQ45CB, update

Cihula, Joseph wrote:
> It took a while, but c/s 203 fixes this issue.

...verified fixed with BIOS rev. 121 and TBoot 816ca

Thank you!
Martin

[tboot-devel] Problem in desktop display with TBOOT & Custom Kernel (FC13)

[Satish K. <sat...@gm...>]

Hello,

I have rebuild custom kernel by just enabling Intel Trusted Exceution
Technology option under Security configuration option. After that i am
trying to boot the system using kernel tboot, SINIT for trusted boot using
this newly build kernel. It boots properly and shows TBOOT messages during
boot but it does not shows proper desktop/display. It shows some square
boxes/lines on my display. Cursor is square box which i was able to move it.


Original kernel - 2.6.33.1-24.fc13.i686
Custom kernel - 2.6.33.4-95.SK.fc13.i686

I built custom kernel using rpmbuild -bp --target=i686 kernel.spec (build
all kernel flavors). Link - http://fedoraproject.org/wiki/Docs/CustomKernel

Please note that i am facing this problem when i boot with tboot. If i boot
using custom kernel which i built without tboot it works fine.
Display/desktop is proper. So i am not able to figure out where exactly the
problem is? Also, i am able to boot properly with tboot and my original
kernel (2.6.33.1-24) and desktop is also coming up properly.

Can you please provide any help to resolve this issue? I had installed
tpm-tools, trousers trousers-devel, tboot.gz, modified grub.conf
accordingly.

I started the system with my original kernel and was getting below error
messages in Automatic Bug Reporting Tool.


WARNING: at mm/highmem.c:444 debug_kmap_atomic+0xad/0x12a()
Hardware name: Sierra
Modules linked in: tpm_infineon ipv6 uinput snd_hda_codec_analog
snd_hda_intel snd_hda_codec e1000e snd_hwdep i2c_i801 snd_seq iTCO_wdt
iTCO_vendor_support snd_seq_device snd_pcm snd_timer snd soundcore serio_raw
snd_page_alloc microcode dm_multipath pata_acpi ata_generic i915
drm_kms_helper drm i2c_algo_bit i2c_core video output [last unloaded:
scsi_wait_scan]
Pid: 0, comm: swapper Tainted: G        W  2.6.33.4-95.SK.fc13.i686 #1
Call Trace:
[<c0c36e2d>] warn_slowpath_common+0x65/0x7c
[<c0caa681>] ? debug_kmap_atomic+0xad/0x12a
[<c0c36e51>] warn_slowpath_null+0xd/0x10
[<c0caa681>] debug_kmap_atomic+0xad/0x12a
[<c0c240a4>] kmap_atomic_prot+0x51/0xd2
[<f7ff5f4d>] ? i915_error_object_create+0x5d/0xfa [i915]
[<c0c24133>] kmap_atomic+0xe/0x10
[<f7ff5f8f>] i915_error_object_create+0x9f/0xfa [i915]
[<f7ff631a>] i915_handle_error+0x330/0x813 [i915]
[<f7ff69a3>] i915_driver_irq_handler+0xc7/0x2f4 [i915]
[<c0c504a3>] ? sched_clock_local+0x17/0x11e
[<c0c78fb4>] handle_IRQ_event+0x52/0xf8
[<c0c7a74a>] handle_edge_irq+0xc7/0x10b
[<c0c04cd3>] handle_irq+0x3b/0x48
[<c0c04558>] do_IRQ+0x41/0x9a
[<c0c03830>] common_interrupt+0x30/0x38
[<c0c5007b>] ? update_target+0x4/0xc0
[<c0df52c9>] ? acpi_idle_enter_bm+0x251/0x282
[<c0ec78b6>] cpuidle_idle_call+0x6d/0xbf
[<c0c024b8>] cpu_idle+0x91/0xad
[<c0f5e59e>] rest_init+0x62/0x64
[<c11b78f1>] start_kernel+0x346/0x34b
[<c11b7099>] i386_start_kernel+0x99/0xa0




-- 
Thanks & Regards,
Satish Kagathara.
Team Lead,
Diebold Software Services Pvt. Ltd.
Mumbai, India.

E-Mail: sat...@gm...
Phone: +91-22-66497573(O) / +91-98693 95421(Mobile)

Re: [tboot-devel] TBoot+Intel DQ45CB, update

[Martin P. <Mar...@ia...>]

Cihula, Joseph wrote:
> It took a while, but c/s 203 fixes this issue.

...verified fixed with BIOS rev. 121 and TBoot 816ca

Thank you!
Martin

Re: [tboot-devel] TBoot+Intel DQ45CB, update

[Cihula, J. <jos...@in...>]

> From: Martin Pirker [mailto:Mar...@ia...]
> Sent: Monday, April 19, 2010 4:17 AM
> 
> Cihula, Joseph wrote:
> > The work around is to disable legacy USB support.  Meanwhile, I will
> > be fixing tboot to not DMA protect these regions when it finds such a
> > case (the current code will not DMA protect reserved regions as long as
> > there is no RAM after them).  This is a non-trivial fix, so it may
> > take a little while.
> 
> Any news on this?

It took a while, but c/s 203 fixes this issue.

Joe

Re: [tboot-devel] Tboot capable core i5/i7 notebooks?

[Martin P. <Mar...@ia...>]

Hi...

Martin Pirker wrote:
> Now that the Core i5/i7 notebook generation is available,

Given a
 Lenovo X201s, BIOS 1.12
 TPM STM 1.2 rev. 8.16
 SINIT i7 v18
 TBoot d5bc75984c1d
 Kernel 2.6.34rc6

Tboot-ing with default 'any' LCP results in
 ERRORCODE: 0x00000000
 no error

:-)

However, the kernel stops some time in ACPI init(?) when TBoot-ed:
...
[    0.006601] ACPI: Core revision 20100121
[   45.278972] DMAR: Host address width 36
...

TBoot/kernel dmesg available on request.

Also, note that not all shiny new components of this laptop are
fully supported by the current latest kernel.

!! All information provided as it, your model may be different
!! and if you brick yours I'm not responsible....


HTH,
Martin

Re: [tboot-devel] compile fails

[Martin P. <Mar...@ia...>]

Wang, Shane wrote:
> Can you send a patch to fix it?

To make it compile:
-static char help[MAX_HELP_TEXT] =
+static char help[MAX_HELP_TEXT+1] =


But thinking about it, that for loop does not care about the size
of the destination buffer. Or as the strncat man page says
"Therefore, the size of dest must be at least strlen(dest)+n+1"
For every strncat operation in that for loop.....


Cihula, Joseph wrote:
> Good catch.  What compiler, and version of it, are you using.  gcc 4.4.3 doesn't catch this.

$ gcc -v
Target: x86_64-pc-linux-gnu
gcc version 4.3.4 (Gentoo 4.3.4 p1.0, pie-10.1.5)


HTH,
Martin

Re: [tboot-devel] compile fails

[Cihula, J. <jos...@in...>]

> From: Martin Pirker [mailto:Mar...@ia...]
> Sent: Monday, April 26, 2010 5:36 AM
>
> Hi...
>
> Compiling latest revision fails with:
>
> In function 'strncat',
>     inlined from 'add_plugins' at crtpolelt.c:118,
>     inlined from 'main' at crtpolelt.c:132:
> /usr/include/bits/string3.h:153: error: call to __builtin___strncat_chk might overflow
> destination buffer
> make[2]: *** [crtpolelt.o] Error 1
> make[2]: Leaving directory `.../hg_tboot/lcptools'
>
>
> crtpolelt.c line 118 is
>   strncat(help, plugin->help_txt, MAX_HELP_TEXT)
>
> and
>   #define MAX_HELP_TEXT       4096
>   static char help[MAX_HELP_TEXT] = .....
>
> so indeed one byte always added by strncat for \0 may be missing
> (see man page).
>
> Martin

Good catch.  What compiler, and version of it, are you using.  gcc 4.4.3 doesn't catch this.

Joe

>
> ------------------------------------------------------------------------------
> _______________________________________________
> tboot-devel mailing list
> tbo...@li...
> https://lists.sourceforge.net/lists/listinfo/tboot-devel

Re: [tboot-devel] compile fails

[Wang, S. <sha...@in...>]

Hi Martin,

Can you send a patch to fix it?

Thanks.
Shane

Martin Pirker wrote:
> Hi...
> 
> Compiling latest revision fails with:
> 
> In function 'strncat',
>     inlined from 'add_plugins' at crtpolelt.c:118,
>     inlined from 'main' at crtpolelt.c:132:
> /usr/include/bits/string3.h:153: error: call to
> __builtin___strncat_chk might overflow destination buffer make[2]:
> *** [crtpolelt.o] Error 1 
> make[2]: Leaving directory `.../hg_tboot/lcptools'
> 
> 
> crtpolelt.c line 118 is
>   strncat(help, plugin->help_txt, MAX_HELP_TEXT)
> 
> and
>   #define MAX_HELP_TEXT       4096
>   static char help[MAX_HELP_TEXT] = .....
> 
> so indeed one byte always added by strncat for \0 may be missing
> (see man page).
> 
> Martin
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> tboot-devel mailing list
> tbo...@li...
> https://lists.sourceforge.net/lists/listinfo/tboot-devel

[tboot-devel] TIW 2010: Summer School on Trustworthy Computing

[Jonathan M. <jon...@cm...>]

---
(Apologies if you receive multiple copies of this announcement!)

TIW 2010: Second Annual Trusted Infrastructure Workshop:
Advanced Summer School on Architectures for Trustworthy Computing
7-11 June 2010, Carnegie Mellon University, Pittsburgh PA, USA
http://www.cylab.cmu.edu/tiw

*** TIW Overview ***

When IT infrastructure technologies fail to keep pace with emerging
threats, we can no longer trust them to sustain the applications we
depend on in both business and society at large.

Ranging from Trusted Computing, to machine virtualization, new
hardware architectures, and new network security architectures,
trusted infrastructure technologies attempt to place security into the
very design of commercial off-the-shelf technologies.

The TIW is an open innovation event modeled as a highly interactive
summer school, consisting of lectures, workshops, and other lab
sessions.  TIW is a collaboration between government, academia, and
industry intended to benefit the cybersecurity research and
development agenda by bringing together researchers in the field.  It
is aimed at bringing together researchers in the field of IT security
with an interest in systems and infrastructure security, as well as MS
or PhD students who are new to the field.  Funding is available to
support student attendance (see below).

*** Agenda Highlights: Lots of new material vs. last year! ***
- 2 keynote lectures
- 10 technology lectures: Trusted Infrastructure 101, Trusted Platform
  Module Deep Dive, Next Generation TPM, Operating System Security,
  Virtualization Security, Storage Security, Network Security,
  High Assurance Platform, Verification and Formal Methods for Trusted
  Computing
- 4 research workshops: Trusted Infrastructure Problem Space and
  Challenges, Security Evaluations, Chains of Trust and Dynamic
  Measurements, Towards Practical Attestation
- 3 hands-on labs: TPM, Trusted Computing Software Stack,
  Dynamic Root of Trust

Several social events and networking with other researchers are planned.

For more details on the workshop and how to register, please visit
http://www.cylab.cmu.edu/tiw

*** Full support student scholarships available! ***

Sponsors are providing student support in the form of scholarships to
aid selected students to attend the workshop. The scholarship includes
coverage of all costs of workshop attendance, including airfare (up to
$500), lodging, and meals. Interested students should register online
and include a brief statement detailing the reason why they would like
to attend. While sponsorships are available in priority to students
from US academia, a small number of sponsorships can will be given to
foreign students, but may not cover full travel or visa fees.


TIW Sponsors

- Carnegie Mellon CyLab
- NSF (pending)
- AMD
- HP Labs
- Wave Systems

Contact:

Registration / logistical details: Tina Yankovich <ti...@an...>
Technical details: Jonathan McCune <jon...@cm...>

Confirmed Speakers

Boris Balacheff, HP Labs
David Challener, Johns Hopkins APL
George Coker, NSA
Paul Congdon, HP
Anupam Datta, CMU
Paul England, Microsoft
Virgil Gligor, CyLab/CMU
Ken Goldman, IBM Research
David Grawrock, Intel
Trent Jaeger, Penn State
Jonathan McCune, CyLab/CMU
Ron Perez, AMD
Adrian Perrig, CyLab/CMU
Stan Potter, NSA
Bob Thibadeau, Wave Systems

Venue

CyLab, Carnegie Mellon University
CIC Building
4720 Forbes Avenue
Pittsburgh, PA 15213

[tboot-devel] compile fails

[Martin P. <Mar...@ia...>]

Hi...

Compiling latest revision fails with:

In function 'strncat',
    inlined from 'add_plugins' at crtpolelt.c:118,
    inlined from 'main' at crtpolelt.c:132:
/usr/include/bits/string3.h:153: error: call to __builtin___strncat_chk might overflow destination buffer
make[2]: *** [crtpolelt.o] Error 1
make[2]: Leaving directory `.../hg_tboot/lcptools'


crtpolelt.c line 118 is
  strncat(help, plugin->help_txt, MAX_HELP_TEXT)

and
  #define MAX_HELP_TEXT       4096
  static char help[MAX_HELP_TEXT] = .....

so indeed one byte always added by strncat for \0 may be missing
(see man page).

Martin