| 2018-05-09 19:04:21 |
dann frazier |
bug |
|
|
added bug |
| 2018-05-09 19:04:30 |
dann frazier |
nominated for series |
|
Ubuntu Bionic |
|
| 2018-05-09 19:04:30 |
dann frazier |
bug task added |
|
linux (Ubuntu Bionic) |
|
| 2018-05-09 19:30:18 |
Ubuntu Kernel Bot |
linux (Ubuntu): status |
New |
Incomplete |
|
| 2018-05-09 19:30:22 |
Ubuntu Kernel Bot |
linux (Ubuntu Bionic): status |
New |
Incomplete |
|
| 2018-05-09 21:27:40 |
dann frazier |
linux (Ubuntu Bionic): assignee |
|
dann frazier (dannf) |
|
| 2018-05-09 21:27:42 |
dann frazier |
linux (Ubuntu): assignee |
|
dann frazier (dannf) |
|
| 2018-05-09 21:28:07 |
dann frazier |
description |
[Impact]
TBD
[Test Case]
TBD
[Fix]
TBD
[Regression Risk]
TBD |
[Impact]
TBD
[Test Case]
TBD
[Fix]
c6d8c8ef1d0d94fdae9f5d72982963db89f9cdad efi: Move ARM CPER code to new file
301f55b1a9177132d2b9ce8a90bf0ae4b37bb850 efi: Parse ARM error information value
[Regression Risk]
TBD |
|
| 2018-05-09 21:28:13 |
dann frazier |
linux (Ubuntu): status |
Incomplete |
Confirmed |
|
| 2018-05-09 21:28:15 |
dann frazier |
linux (Ubuntu Bionic): status |
Incomplete |
Confirmed |
|
| 2018-05-23 20:21:29 |
dann frazier |
description |
[Impact]
TBD
[Test Case]
TBD
[Fix]
c6d8c8ef1d0d94fdae9f5d72982963db89f9cdad efi: Move ARM CPER code to new file
301f55b1a9177132d2b9ce8a90bf0ae4b37bb850 efi: Parse ARM error information value
[Regression Risk]
TBD |
[Impact]
When an ARM-specific platform error (CPER) comes occurs, the kernel will emit an error with an opaque hex error type. The user would then need to consult the UEFI specification to decode it. It would be better to actually do the decoding for the user directly.
[Test Case]
On a server that supports EINJ, generate a fake CE (thanks to Tyler Baicar for this example):
modprobe einj
echo 0x12345000 > /sys/kernel/debug/apei/einj/param1
echo $((-1 << 12)) > /sys/kernel/debug/apei/einj/param2
echo 5 > /sys/kernel/debug/apei/einj/param3
echo 0x3 > /sys/kernel/debug/apei/einj/flags
echo 0x1 > /sys/kernel/debug/apei/einj/error_type
echo 1 > /sys/kernel/debug/apei/einj/error_inject
In the output, look for a decoded message. Without this fix, you'll see:
[ 388.094304] {2}[Hardware Error]: error_info: 0x0000000004c6007f
[ 388.094341] {2}[Hardware Error]: physical fault address: 0x0000000012345000
But with the fix, you'll see:
[ 388.094304] {2}[Hardware Error]: error_info: 0x0000000004c6007f
[ 388.094317] {2}[Hardware Error]: transaction type: Generic
[ 388.094322] {2}[Hardware Error]: operation type: Generic read (type of instruction or data request cannot be determined)
[ 388.094326] {2}[Hardware Error]: cache level: 3
[ 388.094330] {2}[Hardware Error]: processor context not corrupted
[ 388.094333] {2}[Hardware Error]: the error has been corrected
[ 388.094337] {2}[Hardware Error]: PC is imprecise
[ 388.094341] {2}[Hardware Error]: physical fault address: 0x0000000012345000
[Fix]
These upstream fixes add ARM decoding support:
c6d8c8ef1d0d94fdae9f5d72982963db89f9cdad efi: Move ARM CPER code to new file
301f55b1a9177132d2b9ce8a90bf0ae4b37bb850 efi: Parse ARM error information value
[Regression Risk] |
|
| 2018-05-23 23:52:13 |
dann frazier |
linux (Ubuntu): status |
Confirmed |
In Progress |
|
| 2018-05-23 23:52:15 |
dann frazier |
linux (Ubuntu Bionic): status |
Confirmed |
In Progress |
|
| 2018-05-23 23:54:00 |
dann frazier |
description |
[Impact]
When an ARM-specific platform error (CPER) comes occurs, the kernel will emit an error with an opaque hex error type. The user would then need to consult the UEFI specification to decode it. It would be better to actually do the decoding for the user directly.
[Test Case]
On a server that supports EINJ, generate a fake CE (thanks to Tyler Baicar for this example):
modprobe einj
echo 0x12345000 > /sys/kernel/debug/apei/einj/param1
echo $((-1 << 12)) > /sys/kernel/debug/apei/einj/param2
echo 5 > /sys/kernel/debug/apei/einj/param3
echo 0x3 > /sys/kernel/debug/apei/einj/flags
echo 0x1 > /sys/kernel/debug/apei/einj/error_type
echo 1 > /sys/kernel/debug/apei/einj/error_inject
In the output, look for a decoded message. Without this fix, you'll see:
[ 388.094304] {2}[Hardware Error]: error_info: 0x0000000004c6007f
[ 388.094341] {2}[Hardware Error]: physical fault address: 0x0000000012345000
But with the fix, you'll see:
[ 388.094304] {2}[Hardware Error]: error_info: 0x0000000004c6007f
[ 388.094317] {2}[Hardware Error]: transaction type: Generic
[ 388.094322] {2}[Hardware Error]: operation type: Generic read (type of instruction or data request cannot be determined)
[ 388.094326] {2}[Hardware Error]: cache level: 3
[ 388.094330] {2}[Hardware Error]: processor context not corrupted
[ 388.094333] {2}[Hardware Error]: the error has been corrected
[ 388.094337] {2}[Hardware Error]: PC is imprecise
[ 388.094341] {2}[Hardware Error]: physical fault address: 0x0000000012345000
[Fix]
These upstream fixes add ARM decoding support:
c6d8c8ef1d0d94fdae9f5d72982963db89f9cdad efi: Move ARM CPER code to new file
301f55b1a9177132d2b9ce8a90bf0ae4b37bb850 efi: Parse ARM error information value
[Regression Risk] |
[Impact]
When an ARM-specific platform error (CPER) comes occurs, the kernel will emit an error with an opaque hex error type. The user would then need to consult the UEFI specification to decode it. It is far easier for the kernel to do the decoding itself, and just tell the user what the problem is.
[Test Case]
On a server that supports EINJ, generate a fake CE (thanks to Tyler Baicar for this example):
modprobe einj
echo 0x12345000 > /sys/kernel/debug/apei/einj/param1
echo $((-1 << 12)) > /sys/kernel/debug/apei/einj/param2
echo 5 > /sys/kernel/debug/apei/einj/param3
echo 0x3 > /sys/kernel/debug/apei/einj/flags
echo 0x1 > /sys/kernel/debug/apei/einj/error_type
echo 1 > /sys/kernel/debug/apei/einj/error_inject
In the output, look for a decoded message. Without this fix, you'll see:
[ 388.094304] {2}[Hardware Error]: error_info: 0x0000000004c6007f
[ 388.094341] {2}[Hardware Error]: physical fault address: 0x0000000012345000
But with the fix, you'll see:
[ 388.094304] {2}[Hardware Error]: error_info: 0x0000000004c6007f
[ 388.094317] {2}[Hardware Error]: transaction type: Generic
[ 388.094322] {2}[Hardware Error]: operation type: Generic read (type of instruction or data request cannot be determined)
[ 388.094326] {2}[Hardware Error]: cache level: 3
[ 388.094330] {2}[Hardware Error]: processor context not corrupted
[ 388.094333] {2}[Hardware Error]: the error has been corrected
[ 388.094337] {2}[Hardware Error]: PC is imprecise
[ 388.094341] {2}[Hardware Error]: physical fault address: 0x0000000012345000
[Fix]
These upstream fixes add ARM decoding support:
c6d8c8ef1d0d94fdae9f5d72982963db89f9cdad efi: Move ARM CPER code to new file
301f55b1a9177132d2b9ce8a90bf0ae4b37bb850 efi: Parse ARM error information value
[Regression Risk] |
|
| 2018-05-24 00:00:13 |
dann frazier |
description |
[Impact]
When an ARM-specific platform error (CPER) comes occurs, the kernel will emit an error with an opaque hex error type. The user would then need to consult the UEFI specification to decode it. It is far easier for the kernel to do the decoding itself, and just tell the user what the problem is.
[Test Case]
On a server that supports EINJ, generate a fake CE (thanks to Tyler Baicar for this example):
modprobe einj
echo 0x12345000 > /sys/kernel/debug/apei/einj/param1
echo $((-1 << 12)) > /sys/kernel/debug/apei/einj/param2
echo 5 > /sys/kernel/debug/apei/einj/param3
echo 0x3 > /sys/kernel/debug/apei/einj/flags
echo 0x1 > /sys/kernel/debug/apei/einj/error_type
echo 1 > /sys/kernel/debug/apei/einj/error_inject
In the output, look for a decoded message. Without this fix, you'll see:
[ 388.094304] {2}[Hardware Error]: error_info: 0x0000000004c6007f
[ 388.094341] {2}[Hardware Error]: physical fault address: 0x0000000012345000
But with the fix, you'll see:
[ 388.094304] {2}[Hardware Error]: error_info: 0x0000000004c6007f
[ 388.094317] {2}[Hardware Error]: transaction type: Generic
[ 388.094322] {2}[Hardware Error]: operation type: Generic read (type of instruction or data request cannot be determined)
[ 388.094326] {2}[Hardware Error]: cache level: 3
[ 388.094330] {2}[Hardware Error]: processor context not corrupted
[ 388.094333] {2}[Hardware Error]: the error has been corrected
[ 388.094337] {2}[Hardware Error]: PC is imprecise
[ 388.094341] {2}[Hardware Error]: physical fault address: 0x0000000012345000
[Fix]
These upstream fixes add ARM decoding support:
c6d8c8ef1d0d94fdae9f5d72982963db89f9cdad efi: Move ARM CPER code to new file
301f55b1a9177132d2b9ce8a90bf0ae4b37bb850 efi: Parse ARM error information value
[Regression Risk] |
[Impact]
When an ARM-specific platform error (CPER) comes occurs, the kernel will emit an error with an opaque hex error type. The user would then need to consult the UEFI specification to decode it. It is far easier for the kernel to do the decoding itself, and just tell the user what the problem is.
[Test Case]
On a server that supports EINJ, generate a fake CE (thanks to Tyler Baicar for this example):
modprobe einj
echo 0x12345000 > /sys/kernel/debug/apei/einj/param1
echo $((-1 << 12)) > /sys/kernel/debug/apei/einj/param2
echo 5 > /sys/kernel/debug/apei/einj/param3
echo 0x3 > /sys/kernel/debug/apei/einj/flags
echo 0x1 > /sys/kernel/debug/apei/einj/error_type
echo 1 > /sys/kernel/debug/apei/einj/error_inject
In the output, look for a decoded message. Without this fix, you'll see:
[ 388.094304] {2}[Hardware Error]: error_info: 0x0000000004c6007f
[ 388.094341] {2}[Hardware Error]: physical fault address: 0x0000000012345000
But with the fix, you'll see:
[ 388.094304] {2}[Hardware Error]: error_info: 0x0000000004c6007f
[ 388.094317] {2}[Hardware Error]: transaction type: Generic
[ 388.094322] {2}[Hardware Error]: operation type: Generic read (type of instruction or data request cannot be determined)
[ 388.094326] {2}[Hardware Error]: cache level: 3
[ 388.094330] {2}[Hardware Error]: processor context not corrupted
[ 388.094333] {2}[Hardware Error]: the error has been corrected
[ 388.094337] {2}[Hardware Error]: PC is imprecise
[ 388.094341] {2}[Hardware Error]: physical fault address: 0x0000000012345000
[Fix]
These upstream fixes add ARM decoding support:
c6d8c8ef1d0d94fdae9f5d72982963db89f9cdad efi: Move ARM CPER code to new file
301f55b1a9177132d2b9ce8a90bf0ae4b37bb850 efi: Parse ARM error information value
[Regression Risk]
The code changed is specific to ARM, and has been tested there. There's a small change to arch-independent code, but it just involves renaming an array and adding the obviously correct const attribute. |
|
| 2018-06-07 22:50:46 |
Khaled El Mously |
linux (Ubuntu Bionic): status |
In Progress |
Fix Committed |
|
| 2018-06-14 11:02:25 |
Brad Figg |
tags |
|
verification-needed-bionic |
|
| 2018-06-14 22:33:14 |
dann frazier |
tags |
verification-needed-bionic |
verification-done-bionic |
|
| 2018-07-02 08:27:55 |
Launchpad Janitor |
linux (Ubuntu Bionic): status |
Fix Committed |
Fix Released |
|
| 2018-07-02 08:27:55 |
Launchpad Janitor |
cve linked |
|
2018-11508 |
|
| 2018-07-02 08:27:55 |
Launchpad Janitor |
cve linked |
|
2018-7755 |
|
| 2018-07-26 05:13:52 |
Launchpad Janitor |
linux (Ubuntu): status |
In Progress |
Fix Released |
|
