[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [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> _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |