Michael Gissing | 15 Jul 10:24 2010
Picon

Incorrect command line handling with GRUB 1.97 and above

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/grub-devel <at> gnu.org/msg11801.html
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=557645

------------------------------------------------------------------------------
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
Michael Gissing | 15 Jul 13:25 2010
Picon

[PATCH] fix some build issues

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

Attachment (fix_off_by_one.patch): text/x-patch, 430 bytes
Attachment (fix_strncat_usage.patch): text/x-patch, 364 bytes
------------------------------------------------------------------------------
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
tboot-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel
(Continue reading)

Cihula, Joseph | 15 Jul 22:38 2010
Picon

Re: [PATCH] fix some build issues

> From: Michael Gissing [mailto:m.gissing <at> tugraz.at]
> 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

------------------------------------------------------------------------------
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
Michael Gissing | 16 Jul 09:49 2010
Picon

Re: [PATCH] fix some build issues

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.gissing <at> tugraz.at>

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

------------------------------------------------------------------------------
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
陈进 | 16 Jul 10:54 2010
Picon

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.
------------------------------------------------------------------------------
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
tboot-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel
Cihula, Joseph | 16 Jul 19:11 2010
Picon

Re: Help: error code 0xc0000c71

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

 

Joe

 

From: 陈进 [mailto:ciccinocj <at> gmail.com]
Sent: Friday, July 16, 2010 1:55 AM
To: tboot-devel <at> lists.sourceforge.net
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.

------------------------------------------------------------------------------
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
tboot-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel
Michael Gissing | 22 Jul 17:00 2010
Picon

Re: Incorrect command line handling with GRUB 1.97 and above

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
------------------------------------------------------------------------------
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
tboot-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel
Jonathan McCune | 22 Jul 23:02 2010
Picon

Re: GETSEC[SENTER] fail on HP dc7800

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 <martin <at> thiim.net> 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.finney <at> gmail.com> 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
> tboot-devel <at> lists.sourceforge.net
> 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
Jonathan McCune | 23 Jul 01:01 2010
Picon

Re: GETSEC[SENTER] fail on HP dc7800

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 <jonmccune <at> cmu.edu> 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 <martin <at> thiim.net> 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.finney <at> gmail.com> 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
>> tboot-devel <at> lists.sourceforge.net
>> 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
Cihula, Joseph | 23 Jul 03:28 2010
Picon

Re: GETSEC[SENTER] fail on HP dc7800

> From: Jonathan McCune [mailto:jonmccune <at> cmu.edu]
> 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 <jonmccune <at> cmu.edu> 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 <martin <at> thiim.net> 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.finney <at> gmail.com> 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
> >> tboot-devel <at> lists.sourceforge.net
> >> 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
> tboot-devel <at> lists.sourceforge.net
> 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

Gmane