Description of problem:
On a 32-bit system, I get five fields under smbios.system:

#  lshal | grep smbios.system
  smbios.system.uuid = 'EF861801-45B9-11CB-88E3-AFBFE5370493'  (string)
  smbios.system.serial = 'KBPKNB2'  (string)
  smbios.system.version = 'ThinkPad X31'  (string)
  smbios.system.product = '2672JHG'  (string)
  smbios.system.manufacturer = 'IBM'  (string)

However on a 64-bit system, I only get 4, with UUID being missing

# lshal | grep smbios.system
  smbios.system.serial = 'None'  (string)
  smbios.system.version = 'Rev 1'  (string)
  smbios.system.product = 'Dune/Sahara'  (string)
  smbios.system.manufacturer = 'AMD'  (string)

If I run the dmidecode tool, the UUID info is definitely present & correct in
the expected data fields:

# dmidecode | grep --after 5 "System Information"
System Information
        Manufacturer: AMD
        Product Name: Dune/Sahara
        Version: Rev 1
        Serial Number: None
        UUID: 005F9CF0-C488-0010-A593-B114B6200390




Version-Release number of selected component (if applicable):


How reproducible:
Always on 64-bit

Steps to Reproduce:
1. Run  "lshal | grep smbios.system.uuid"
2.
3.
  
Actual results:
No matches

Expected results:
Displays the UUID

Additional info:
The bug is caused by mistaken use of 'sizeof' instead of 'strlen' in code
parsing DMI output. Bug is apparently fixed in upstream CVS. The reliable
reporting of UUID from DMI data will be essential for management tools running
in Xen guest domains, enabling them to associate Dom0<->DomU.