Invalid length provided for SMBIOS data

Invalid length provided for SMBIOS data

[Daniel P. Berrange]

I was running some tests of HVM guests on Fedora Core 6, test3 and came
across a potential issue with SMBIOS data. When running dmidecode in the
guest VMs it reports that the actual SMBIOS data size, does not match
the advertised size. eg

"Wrong DMI structures length: 439 bytes announced, structures occupy 363 bytes."

I've tried this in a variety of guest OS (RHEL-3 32-bit, RHEL-3 64-bit,
RHEL-4 64-bit) all the same results. The host is running FC6 test3, but
the bit of code responsible for constructing the SMBIOS tables is identical
to that on the vanilla xen-unstable.hg  repository. I'm not familiar 
enough with SMBIOS specs / code to determine where the mistake in the
length calculation is though...

Is anyone else seeing this length mismatch in HVM guests ?

FYI, we're tracking this as https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=207501

Regards,
Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 

Re: Invalid length provided for SMBIOS data

[Andrew D. Ball]

This is seriously broken -- I'll write a patch as soon as I can, unless
somebody beats me to it :-)

Peace.
Andrew

On Wed, 2006-09-27 at 19:03 +0100, Daniel P. Berrange wrote:
> I was running some tests of HVM guests on Fedora Core 6, test3 and came
> across a potential issue with SMBIOS data. When running dmidecode in the
> guest VMs it reports that the actual SMBIOS data size, does not match
> the advertised size. eg
> 
> "Wrong DMI structures length: 439 bytes announced, structures occupy 363 bytes."
> 
> I've tried this in a variety of guest OS (RHEL-3 32-bit, RHEL-3 64-bit,
> RHEL-4 64-bit) all the same results. The host is running FC6 test3, but
> the bit of code responsible for constructing the SMBIOS tables is identical
> to that on the vanilla xen-unstable.hg  repository. I'm not familiar 
> enough with SMBIOS specs / code to determine where the mistake in the
> length calculation is though...
> 
> Is anyone else seeing this length mismatch in HVM guests ?
> 
> FYI, we're tracking this as https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=207501
> 
> Regards,
> Dan.

Re: Invalid length provided for SMBIOS data

[Keir Fraser]

I've checked in a simplification of the SMBIOS code as changeset 11686 in
xen-unstable. Since this entirely removes the code that computes the table
size 'ahead of time', it is very likely to fix this bug. We now *definitely*
write the number of bytes that we actually emitted when constructing the
tables. So unless the tables themselves are screwed, the length field must
now surely be correct.

 -- Keir

On 2/10/06 15:10, "Andrew D. Ball" <aball@us.ibm.com> wrote:

> This is seriously broken -- I'll write a patch as soon as I can, unless
> somebody beats me to it :-)
> 
> Peace.
> Andrew
> 
> On Wed, 2006-09-27 at 19:03 +0100, Daniel P. Berrange wrote:
>> I was running some tests of HVM guests on Fedora Core 6, test3 and came
>> across a potential issue with SMBIOS data. When running dmidecode in the
>> guest VMs it reports that the actual SMBIOS data size, does not match
>> the advertised size. eg
>> 
>> "Wrong DMI structures length: 439 bytes announced, structures occupy 363
>> bytes."
>> 
>> I've tried this in a variety of guest OS (RHEL-3 32-bit, RHEL-3 64-bit,
>> RHEL-4 64-bit) all the same results. The host is running FC6 test3, but
>> the bit of code responsible for constructing the SMBIOS tables is identical
>> to that on the vanilla xen-unstable.hg  repository. I'm not familiar
>> enough with SMBIOS specs / code to determine where the mistake in the
>> length calculation is though...
>> 
>> Is anyone else seeing this length mismatch in HVM guests ?
>> 
>> FYI, we're tracking this as
>> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=207501
>> 
>> Regards,
>> Dan.
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

Re: Invalid length provided for SMBIOS data

[Andrew D. Ball]

Is this in some sort of staging tree?  I don't see it in xen-unstable.hg
yet.  If so, can I pull it from somewhere?

Peace.
Andrew

On Mon, 2006-10-02 at 18:13 +0100, Keir Fraser wrote:
> I've checked in a simplification of the SMBIOS code as changeset 11686 in
> xen-unstable. Since this entirely removes the code that computes the table
> size 'ahead of time', it is very likely to fix this bug. We now *definitely*
> write the number of bytes that we actually emitted when constructing the
> tables. So unless the tables themselves are screwed, the length field must
> now surely be correct.
> 
>  -- Keir
> 
> On 2/10/06 15:10, "Andrew D. Ball" <aball@us.ibm.com> wrote:
> 
> > This is seriously broken -- I'll write a patch as soon as I can, unless
> > somebody beats me to it :-)
> > 
> > Peace.
> > Andrew
> > 
> > On Wed, 2006-09-27 at 19:03 +0100, Daniel P. Berrange wrote:
> >> I was running some tests of HVM guests on Fedora Core 6, test3 and came
> >> across a potential issue with SMBIOS data. When running dmidecode in the
> >> guest VMs it reports that the actual SMBIOS data size, does not match
> >> the advertised size. eg
> >> 
> >> "Wrong DMI structures length: 439 bytes announced, structures occupy 363
> >> bytes."
> >> 
> >> I've tried this in a variety of guest OS (RHEL-3 32-bit, RHEL-3 64-bit,
> >> RHEL-4 64-bit) all the same results. The host is running FC6 test3, but
> >> the bit of code responsible for constructing the SMBIOS tables is identical
> >> to that on the vanilla xen-unstable.hg  repository. I'm not familiar
> >> enough with SMBIOS specs / code to determine where the mistake in the
> >> length calculation is though...
> >> 
> >> Is anyone else seeing this length mismatch in HVM guests ?
> >> 
> >> FYI, we're tracking this as
> >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=207501
> >> 
> >> Regards,
> >> Dan.
> > 
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> 
> 

Re: Invalid length provided for SMBIOS data

[Keir Fraser]

It's in the public tree now.

 K.

On 2/10/06 6:52 pm, "Andrew D. Ball" <aball@us.ibm.com> wrote:

> Is this in some sort of staging tree?  I don't see it in xen-unstable.hg
> yet.  If so, can I pull it from somewhere?
> 
> Peace.
> Andrew
> 
> On Mon, 2006-10-02 at 18:13 +0100, Keir Fraser wrote:
>> I've checked in a simplification of the SMBIOS code as changeset 11686 in
>> xen-unstable. Since this entirely removes the code that computes the table
>> size 'ahead of time', it is very likely to fix this bug. We now *definitely*
>> write the number of bytes that we actually emitted when constructing the
>> tables. So unless the tables themselves are screwed, the length field must
>> now surely be correct.
>> 
>>  -- Keir
>> 
>> On 2/10/06 15:10, "Andrew D. Ball" <aball@us.ibm.com> wrote:
>> 
>>> This is seriously broken -- I'll write a patch as soon as I can, unless
>>> somebody beats me to it :-)
>>> 
>>> Peace.
>>> Andrew
>>> 
>>> On Wed, 2006-09-27 at 19:03 +0100, Daniel P. Berrange wrote:
>>>> I was running some tests of HVM guests on Fedora Core 6, test3 and came
>>>> across a potential issue with SMBIOS data. When running dmidecode in the
>>>> guest VMs it reports that the actual SMBIOS data size, does not match
>>>> the advertised size. eg
>>>> 
>>>> "Wrong DMI structures length: 439 bytes announced, structures occupy 363
>>>> bytes."
>>>> 
>>>> I've tried this in a variety of guest OS (RHEL-3 32-bit, RHEL-3 64-bit,
>>>> RHEL-4 64-bit) all the same results. The host is running FC6 test3, but
>>>> the bit of code responsible for constructing the SMBIOS tables is identical
>>>> to that on the vanilla xen-unstable.hg  repository. I'm not familiar
>>>> enough with SMBIOS specs / code to determine where the mistake in the
>>>> length calculation is though...
>>>> 
>>>> Is anyone else seeing this length mismatch in HVM guests ?
>>>> 
>>>> FYI, we're tracking this as
>>>> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=207501
>>>> 
>>>> Regards,
>>>> Dan.
>>> 
>>> 
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xensource.com
>>> http://lists.xensource.com/xen-devel
>> 
>> 
> 

Re: Invalid length provided for SMBIOS data

[Daniel P. Berrange]

[-- Attachment #1: Type: text/plain, Size: 1190 bytes --]

On Mon, Oct 02, 2006 at 06:13:37PM +0100, Keir Fraser wrote:
> I've checked in a simplification of the SMBIOS code as changeset 11686 in
> xen-unstable. Since this entirely removes the code that computes the table
> size 'ahead of time', it is very likely to fix this bug. We now *definitely*
> write the number of bytes that we actually emitted when constructing the
> tables. So unless the tables themselves are screwed, the length field must
> now surely be correct.

And indeed the one of the tables was screwed. There is a sneaky typo
in calculating how far to advance the pointer in the CPU table - its
doing  strlen(buf) instead of strlen(cpu_manufactuerer) which on my
particular system offset things by 6 bytes. Attaching the trivial
patch to fix it - applies on top of your patch in 11686.

  Signed-of-by: Daniel P. Berrange <berrange@redhat.com>

Regards,
Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 

[-- Attachment #2: xen-smbios-length-2.patch --]
[-- Type: text/plain, Size: 568 bytes --]

diff -ru xen-3.0.3-testing-11633.smbios-orig/tools/firmware/hvmloader/smbios.c xen-3.0.3-testing-11633.smbios/tools/firmware/hvmloader/smbios.c
--- xen-3.0.3-testing-11633.smbios-orig/tools/firmware/hvmloader/smbios.c	2006-10-03 16:02:57.000000000 -0400
+++ xen-3.0.3-testing-11633.smbios/tools/firmware/hvmloader/smbios.c	2006-10-03 16:01:17.000000000 -0400
@@ -434,7 +434,7 @@
 	start += strlen(buf) + 1;
 
 	strcpy((char *)start, cpu_manufacturer);
-	start += strlen(buf) + 1;
+	start += strlen(cpu_manufacturer) + 1;
 
 	*((uint8_t *)start) = 0;
 	return start+1;

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: Invalid length provided for SMBIOS data

[Andrew D. Ball]

I wonder if some of the smbios tables are squashed...  I have [much
to my chagrin] a hard-coded the starting address and size of the 
tables:

/* These constants must agree with the ACPI e820 memory map as defined
   in tools/libxc/xc_hvm_build.c and the address the ROMBIOS pulls the
   SMBIOS entry point from in the smbios_init subroutine.
 */
#define SMBIOS_PHYSICAL_ADDRESS 0x9f000
#define SMBIOS_SIZE_LIMIT 0x800

I'll look at what data I get from a 64-bit domU as soon as I can get to
my VT machine.  You're welcome to futz around as well.  The dmidecode
isn't terribly difficult to read.  I've also written a tool to examine
memory by physical (will be pseudo-physical in this case) address that
I'd be happy to share.

Peace.
Andrew

On Mon, 2006-10-02 at 16:48 +0100, Daniel P. Berrange wrote:
> On Mon, Oct 02, 2006 at 11:15:58AM -0400, Andrew D. Ball wrote:
> > Please post the domU's configuration.  Looks like the type 4 (cpu
> > information) generation is broken.
> 
> Here's the config from my RHEL-3, x86_64  guest
> 
> # Automatically generated xen config file
> name = "rhel3x86_64"
> builder = "hvm"
> memory = "500"
> disk = [ 'file:/xen/rhel3x86_64.img,hda,w', ]
> vif = [ 'mac=00:16:3e:05:eb:04, bridge=xenbr0', ]
> uuid = "dbc4c892-4b67-bc7a-895a-a6b5f56ff061"
> device_model = "/usr/lib64/xen/bin/qemu-dm"
> kernel = "/usr/lib/xen/boot/hvmloader"
> vnc=1
> vncunused=1
> apic=1
> acpi=0
> pae=1
> vcpus=4
> serial = "pty" 
> on_reboot   = 'restart'
> on_crash    = 'restart'
> 
> > On Wed, 2006-09-27 at 19:03 +0100, Daniel P. Berrange wrote:
> > > I was running some tests of HVM guests on Fedora Core 6, test3 and came
> > > across a potential issue with SMBIOS data. When running dmidecode in the
> > > guest VMs it reports that the actual SMBIOS data size, does not match
> > > the advertised size. eg
> > > 
> > > "Wrong DMI structures length: 439 bytes announced, structures occupy 363 bytes."
> > > 
> > > I've tried this in a variety of guest OS (RHEL-3 32-bit, RHEL-3 64-bit,
> > > RHEL-4 64-bit) all the same results. The host is running FC6 test3, but
> > > the bit of code responsible for constructing the SMBIOS tables is identical
> > > to that on the vanilla xen-unstable.hg  repository. I'm not familiar 
> > > enough with SMBIOS specs / code to determine where the mistake in the
> > > length calculation is though...
> > > 
> > > Is anyone else seeing this length mismatch in HVM guests ?
> > > 
> > > FYI, we're tracking this as https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=207501
> > > 
> 
> 
> Dan.

Re: Invalid length provided for SMBIOS data

[Andrew D. Ball]

Is this fixed now?

Peace.
Andrew

On Wed, 2006-09-27 at 19:03 +0100, Daniel P. Berrange wrote:
> I was running some tests of HVM guests on Fedora Core 6, test3 and came
> across a potential issue with SMBIOS data. When running dmidecode in the
> guest VMs it reports that the actual SMBIOS data size, does not match
> the advertised size. eg
> 
> "Wrong DMI structures length: 439 bytes announced, structures occupy 363 bytes."
> 
> I've tried this in a variety of guest OS (RHEL-3 32-bit, RHEL-3 64-bit,
> RHEL-4 64-bit) all the same results. The host is running FC6 test3, but
> the bit of code responsible for constructing the SMBIOS tables is identical
> to that on the vanilla xen-unstable.hg  repository. I'm not familiar 
> enough with SMBIOS specs / code to determine where the mistake in the
> length calculation is though...
> 
> Is anyone else seeing this length mismatch in HVM guests ?
> 
> FYI, we're tracking this as https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=207501
> 
> Regards,
> Dan.