[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[ovmf baseline-only test] 71190: all pass



This run is configured for baseline tests only.

flight 71190 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71190/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf                 f90c4fff00bee5f654ad93afd0f74b99050960de
baseline version:
 ovmf                 36a0d5cab8c9a6ad628ca8e6ccb5d63ed87a53dd

Last test of basis    71188  2017-04-12 20:23:59 Z    0 days
Testing same since    71190  2017-04-13 11:47:06 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Hao Wu <hao.a.wu@xxxxxxxxx>

jobs:
 build-amd64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    


------------------------------------------------------------
sg-report-flight on osstest.xs.citrite.net
logs: /home/osstest/logs
images: /home/osstest/images

Logs, config files, etc. are available at
    http://osstest.xs.citrite.net/~osstest/testlogs/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Push not applicable.

------------------------------------------------------------
commit f90c4fff00bee5f654ad93afd0f74b99050960de
Author: Hao Wu <hao.a.wu@xxxxxxxxx>
Date:   Wed Apr 12 08:43:10 2017 +0800

    IntelFrameworkModulePkg/IdeBusDxe: Fix undefined behavior in signed left 
shift
    
    In function AtapiReadCapacity(), the following expression:
    IdeDev->BlkIo.Media->LastBlock = (Data.LastLba3 << 24) |
      (Data.LastLba2 << 16) |
      (Data.LastLba1 << 8) |
      Data.LastLba0;
    
    (There is also a similar case in this function.)
    
    will involve undefined behavior in signed left shift operations.
    
    Since Data.LastLbaX is of type UINT8, and
    IdeDev->BlkIo.Media->LastBlock is of type UINT64. Therefore,
    Data.LastLbaX will be promoted to int (32 bits, signed) first,
    and then perform the left shift operation.
    
    According to the C11 spec, Section 6.5.7:
    4 The result of E1 << E2 is E1 left-shifted E2 bit positions; vacated
      bits are filled with zeros. If E1 has an unsigned type, the value
      of the result is E1 * 2^E2 , reduced modulo one more than the
      maximum value representable in the result type. If E1 has a signed
      type and nonnegative value, and E1 * 2^E2 is representable in the
      result type, then that is the resulting value; otherwise, the
      behavior is undefined.
    
    So if bit 7 of Data.LastLba3 is 1, (Data.LastLba3 << 24) will be out of
    the range within int type. The undefined behavior of the signed left shift
    will lead to a potential of setting the high 32 bits of
    IdeDev->BlkIo.Media->LastBlock to 1 during the cast from type int to type
    UINT64.
    
    This commit will add an explicit UINT32 type cast for Data.LastLba3 to
    resolve this issue.
    
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Hao Wu <hao.a.wu@xxxxxxxxx>
    Reviewed-by: Feng Tian <feng.tian@xxxxxxxxx>

commit a2617ed6277aeb62fbde3e428c582912cf9980e2
Author: Hao Wu <hao.a.wu@xxxxxxxxx>
Date:   Wed Apr 12 09:06:36 2017 +0800

    MdeModulePkg/UsbBotPei: Fix undefined behavior in signed left shift
    
    In function PeiUsbReadCapacity(), the following expression:
    LastBlock = (Data.LastLba3 << 24) |
      (Data.LastLba2 << 16) |
      (Data.LastLba1 << 8) |
      Data.LastLba0;
    
    (There is also a similar case in function PeiUsbReadFormattedCapacity().)
    
    will involve undefined behavior in signed left shift operations.
    
    Since Data.LastLbaX is of type UINT8, they will be promoted to int (32
    bits, signed) first, and then perform the left shift operation.
    
    According to the C11 spec, Section 6.5.7:
    4 The result of E1 << E2 is E1 left-shifted E2 bit positions; vacated
      bits are filled with zeros. If E1 has an unsigned type, the value
      of the result is E1 * 2^E2 , reduced modulo one more than the
      maximum value representable in the result type. If E1 has a signed
      type and nonnegative value, and E1 * 2^E2 is representable in the
      result type, then that is the resulting value; otherwise, the
      behavior is undefined.
    
    So if bit 7 of Data.LastLba3 is 1, (Data.LastLba3 << 24) will be out of
    the range within int type. The undefined behavior of the signed left shift
    might incur potential issues.
    
    This commit will add an explicit UINT32 type cast for Data.LastLba3 to
    refine the codes.
    
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Hao Wu <hao.a.wu@xxxxxxxxx>
    Reviewed-by: Feng Tian <feng.tian@xxxxxxxxx>

commit da117dda23955250e63052d3504edfb38439f12c
Author: Hao Wu <hao.a.wu@xxxxxxxxx>
Date:   Wed Apr 12 09:00:18 2017 +0800

    MdeModulePkg/UfsBlkIoPei: Fix undefined behavior in signed left shift
    
    In function UfsBlockIoPeimGetMediaInfo(), the following expression:
    Private->Media[DeviceIndex].LastBlock  = (Capacity16.LastLba3 << 24) |
      (Capacity16.LastLba2 << 16) |
      (Capacity16.LastLba1 << 8) |
      Capacity16.LastLba0;
    
    (There is also a similar case in this function.)
    
    will involve undefined behavior in signed left shift operations.
    
    Since Capacity16.LastLbaX is of type UINT8, and
    Private->Media[DeviceIndex].LastBlock is of type UINT64. Therefore,
    Capacity16.LastLbaX will be promoted to int (32 bits, signed) first, and
    then perform the left shift operation.
    
    According to the C11 spec, Section 6.5.7:
    4 The result of E1 << E2 is E1 left-shifted E2 bit positions; vacated
      bits are filled with zeros. If E1 has an unsigned type, the value
      of the result is E1 * 2^E2 , reduced modulo one more than the
      maximum value representable in the result type. If E1 has a signed
      type and nonnegative value, and E1 * 2^E2 is representable in the
      result type, then that is the resulting value; otherwise, the
      behavior is undefined.
    
    So if bit 7 of Capacity16.LastLba3 is 1, (Capacity16.LastLba3 << 24) will
    be out of the range within int type. The undefined behavior of the signed
    left shift will lead to a potential of setting the high 32 bits of
    Private->Media[DeviceIndex].LastBlock to 1 during the cast from type int
    to type UINT64.
    
    This commit will add an explicit UINT32 type cast for Capacity16.LastLba3
    to resolve this issue.
    
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Hao Wu <hao.a.wu@xxxxxxxxx>
    Reviewed-by: Feng Tian <feng.tian@xxxxxxxxx>

commit 3778a4dfcd8d8286de3eed6fb5e33871854879e5
Author: Hao Wu <hao.a.wu@xxxxxxxxx>
Date:   Wed Apr 12 08:52:51 2017 +0800

    MdeModulePkg/IdeBusPei: Fix undefined behavior in signed left shift
    
    In function ReadCapacity(), the following expression:
    MediaInfo->LastBlock = (Data.LastLba3 << 24) |
      (Data.LastLba2 << 16) |
      (Data.LastLba1 << 8) |
      Data.LastLba0;
    
    (There is also a similar case in this function.)
    
    will involve undefined behavior in signed left shift operations.
    
    Since Data.LastLbaX is of type UINT8, and MediaInfo->LastBlock is of type
    UINTN. Therefore, Data.LastLbaX will be promoted to int (32 bits, signed)
    first, and then perform the left shift operation.
    
    According to the C11 spec, Section 6.5.7:
    4 The result of E1 << E2 is E1 left-shifted E2 bit positions; vacated
      bits are filled with zeros. If E1 has an unsigned type, the value
      of the result is E1 * 2^E2 , reduced modulo one more than the
      maximum value representable in the result type. If E1 has a signed
      type and nonnegative value, and E1 * 2^E2 is representable in the
      result type, then that is the resulting value; otherwise, the
      behavior is undefined.
    
    So if bit 7 of Data.LastLba3 is 1, (Data.LastLba3 << 24) will be out of
    the range within int type. The undefined behavior of the signed left shift
    will lead to a potential of setting the high 32 bits of
    MediaInfo->LastBlock to 1 during the cast from type int to type UINT64
    for X64 builds.
    
    This commit will add an explicit UINT32 type cast for Data.LastLba3 to
    resolve this issue.
    
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Hao Wu <hao.a.wu@xxxxxxxxx>
    Reviewed-by: Feng Tian <feng.tian@xxxxxxxxx>

commit 7c115e775b439661b06e84edda0670098c81d354
Author: Hao Wu <hao.a.wu@xxxxxxxxx>
Date:   Mon Mar 20 15:17:36 2017 +0800

    MdeModulePkg/ScsiDiskDxe: Fix undefined behavior in signed left shift
    
    In function GetMediaInfo(), the following expression:
    ScsiDiskDevice->BlkIo.Media->LastBlock =  (Capacity10->LastLba3 << 24) |
                                              (Capacity10->LastLba2 << 16) |
                                              (Capacity10->LastLba1 << 8)  |
                                               Capacity10->LastLba0;
    will involve undefined behavior in signed left shift operations.
    
    Since Capacity10->LastLbaX is of type UINT8, and
    ScsiDiskDevice->BlkIo.Media->LastBlock is of type UINT64. Therefore,
    Capacity10->LastLbaX will be promoted to int (32 bits, signed) first,
    and then perform the left shift operation.
    
    According to the C11 spec, Section 6.5.7:
    4 The result of E1 << E2 is E1 left-shifted E2 bit positions; vacated
      bits are filled with zeros. If E1 has an unsigned type, the value
      of the result is E1 * 2^E2 , reduced modulo one more than the
      maximum value representable in the result type. If E1 has a signed
      type and nonnegative value, and E1 * 2^E2 is representable in the
      result type, then that is the resulting value; otherwise, the
      behavior is undefined.
    
    So if bit 7 of Capacity10->LastLba3 is 1, (Capacity10->LastLba3 << 24)
    will be out of the range within int type. The undefined behavior of the
    signed left shift will lead to a potential of setting the high 32 bits
    of ScsiDiskDevice->BlkIo.Media->LastBlock to 1 during the cast from type
    int to type UINT64.
    
    This commit will add an explicit UINT32 type cast for
    Capacity10->LastLba3 to resolve this issue.
    
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Hao Wu <hao.a.wu@xxxxxxxxx>
    Reviewed-by: Feng Tian <feng.tian@xxxxxxxxx>
    Reviewed-by: Laszlo Ersek <lersek@xxxxxxxxxx>

commit 7a14d54f6c50a1ff73351e4aaee8570ec5f8a476
Author: Hao Wu <hao.a.wu@xxxxxxxxx>
Date:   Mon Mar 20 16:24:09 2017 +0800

    MdeModulePkg/Dxe/Image: Restore mCurrentImage on all paths
    
    This commit makes sure that in function CoreStartImage(), module
    variable 'mCurrentImage' is restored to the current start image context
    on all code paths.
    
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Hao Wu <hao.a.wu@xxxxxxxxx>
    Reviewed-by: Liming Gao <liming.gao@xxxxxxxxx>

_______________________________________________
osstest-output mailing list
osstest-output@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/cgi-bin/mailman/listinfo/osstest-output

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.