Menu
▾
▴
tboot-devel — Developer support
You can subscribe to this list here.
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(3) |
Dec
(13) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2008 |
Jan
(19) |
Feb
(24) |
Mar
(8) |
Apr
(14) |
May
(8) |
Jun
(10) |
Jul
(14) |
Aug
(3) |
Sep
(13) |
Oct
(27) |
Nov
(39) |
Dec
(24) |
| 2009 |
Jan
(19) |
Feb
(4) |
Mar
(2) |
Apr
(15) |
May
|
Jun
(2) |
Jul
(44) |
Aug
(21) |
Sep
(20) |
Oct
(2) |
Nov
(1) |
Dec
(7) |
| 2010 |
Jan
(7) |
Feb
(10) |
Mar
(2) |
Apr
(12) |
May
(7) |
Jun
(2) |
Jul
(18) |
Aug
(11) |
Sep
(4) |
Oct
(25) |
Nov
(8) |
Dec
(1) |
| 2011 |
Jan
(27) |
Feb
(2) |
Mar
(19) |
Apr
(8) |
May
(16) |
Jun
(11) |
Jul
(9) |
Aug
(9) |
Sep
(35) |
Oct
(9) |
Nov
(8) |
Dec
(32) |
| 2012 |
Jan
(37) |
Feb
(20) |
Mar
(2) |
Apr
(24) |
May
(4) |
Jun
(3) |
Jul
(5) |
Aug
(21) |
Sep
(8) |
Oct
(15) |
Nov
(1) |
Dec
(7) |
| 2013 |
Jan
(4) |
Feb
(8) |
Mar
(38) |
Apr
(9) |
May
(42) |
Jun
(4) |
Jul
(21) |
Aug
(4) |
Sep
|
Oct
(7) |
Nov
(2) |
Dec
(3) |
| 2014 |
Jan
(8) |
Feb
(8) |
Mar
(5) |
Apr
(9) |
May
(19) |
Jun
(1) |
Jul
(10) |
Aug
(25) |
Sep
(6) |
Oct
(2) |
Nov
(5) |
Dec
(1) |
| 2015 |
Jan
|
Feb
|
Mar
(5) |
Apr
|
May
(12) |
Jun
|
Jul
(2) |
Aug
(5) |
Sep
(11) |
Oct
(5) |
Nov
(3) |
Dec
(1) |
| 2016 |
Jan
(2) |
Feb
(24) |
Mar
|
Apr
(6) |
May
(26) |
Jun
(20) |
Jul
(8) |
Aug
(15) |
Sep
(21) |
Oct
(1) |
Nov
(7) |
Dec
(24) |
| 2017 |
Jan
(12) |
Feb
(2) |
Mar
(6) |
Apr
(8) |
May
(18) |
Jun
(13) |
Jul
(12) |
Aug
(8) |
Sep
(5) |
Oct
(1) |
Nov
|
Dec
|
| 2018 |
Jan
(2) |
Feb
(12) |
Mar
(8) |
Apr
(5) |
May
(7) |
Jun
(1) |
Jul
(4) |
Aug
(8) |
Sep
(2) |
Oct
(3) |
Nov
(4) |
Dec
(3) |
| 2019 |
Jan
(8) |
Feb
|
Mar
(2) |
Apr
|
May
(3) |
Jun
(4) |
Jul
(1) |
Aug
|
Sep
(8) |
Oct
(6) |
Nov
(20) |
Dec
(14) |
| 2020 |
Jan
(25) |
Feb
(12) |
Mar
(2) |
Apr
(13) |
May
(44) |
Jun
(9) |
Jul
|
Aug
(3) |
Sep
(5) |
Oct
(4) |
Nov
(2) |
Dec
|
| 2021 |
Jan
(6) |
Feb
|
Mar
(7) |
Apr
(1) |
May
|
Jun
(2) |
Jul
|
Aug
(16) |
Sep
(4) |
Oct
(6) |
Nov
(1) |
Dec
(6) |
| 2022 |
Jan
(5) |
Feb
(4) |
Mar
(22) |
Apr
(6) |
May
(4) |
Jun
(17) |
Jul
(2) |
Aug
|
Sep
|
Oct
(2) |
Nov
(1) |
Dec
(2) |
| 2023 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2024 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2025 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: N0T3P4D <n0t...@gm...> - 2025-01-08 19:02:29
|
Hi,
I'm unable to get a successful TXT boot on the Protectli VP6670 (12th Gen Intel(R) Core(TM) i7-1255U) using tboot 1.11.9 and the latest (non-coreboot) UEFI firmware 1.80 on Gentoo
Linux. TXT is enabled in the firmware and the kernel.
The SINIT ACM module does not seem to be included in the firmware and is provided as the last multiboot2 module in GRUB.
txt-info shows
Intel(r) TXT Configuration Registers:
STS: 0x00000002
senter_done: FALSE
sexit_done: TRUE
mem_config_lock: FALSE
private_open: FALSE
locality_1_open: FALSE
locality_2_open: FALSE
ESTS: 0x00
txt_reset: FALSE
E2STS: 0x0000000000000004
secrets: FALSE
ERRORCODE: 0x00000000
DIDVID: 0x00000001b00c8086
vendor_id: 0x8086
device_id: 0xb00c
revision_id: 0x1
FSBIF: 0xffffffffffffffff
QPIIF: 0x000000009d003000
SINIT.BASE: 0x00000000
SINIT.SIZE: 0B (0x0)
HEAP.BASE: 0x00000000
HEAP.SIZE: 0B (0x0)
DPR: 0x0000000000000000
lock: FALSE
top: 0x00000000
size: 0MB (0B)
PUBLIC.KEY:
87 9a 8f 9c bf 9e 3d 1d 12 dc 9a d7 6d de 34 e6
aa 40 36 64 c7 39 db 34 7b 85 8f 0b e0 33 ae 3a
***********************************************************
TXT measured launch: FALSE
secrets flag set: FALSE
The TXT error log (see below for full log) does not show an explicit error. The only interesting part seems to be related to SINIT ACM:
TBOOT: chipset ids: vendor: 0x8086, device: 0xb00c, revision: 0x1
TBOOT: processor family/model/stepping: 0x906a4
TBOOT: platform id: 0x1c000000000000
TBOOT: 3 ACM chipset id entries:
TBOOT: vendor: 0x8086, device: 0xb00f, flags: 0x1, revision: 0x1, extended: 0x0
TBOOT: vendor: 0x8086, device: 0xb012, flags: 0x1, revision: 0x1, extended: 0x0
TBOOT: vendor: 0x8086, device: 0xb00c, flags: 0x1, revision: 0x1, extended: 0x0
TBOOT: 6 ACM processor id entries:
TBOOT: fms: 0x90670, fms_mask: 0xfff3ff0, platform_id: 0x0, platform_mask: 0x0
TBOOT: fms: 0x906a0, fms_mask: 0xfff3ff0, platform_id: 0x0, platform_mask: 0x0
TBOOT: SINIT matches platform
TBOOT: TXT.SINIT.BASE: 0x0
TBOOT: TXT.SINIT.SIZE: 0x0 (0)
TBOOT: BIOS-reserved SINIT size (0) is too small for loaded SINIT (1fdc0)
TBOOT: SINIT ACM not provided.
txt-acminfo /boot/ADL_SINIT_v1_18_16_20230427_REL_NT_O1.PW_signed.bin (see below for full output) finishes with
ERROR: No TXT heap is available
Any help is appreciated!
Best regards
N0T3P4D
-----
txt-acminfo /boot/ADL_SINIT_v1_18_16_20230427_REL_NT_O1.PW_signed.bin
AC module header dump for /boot/ADL_SINIT_v1_18_16_20230427_REL_NT_O1.PW_signed.bin:
type: 0x2 (ACM_TYPE_CHIPSET)
subtype: 0x0
length: 0xe0 (224)
version: 196608
chipset_id: 0xb00c
flags: 0x0
pre_production: 0
debug_signed: 0
vendor: 0x8086
date: 0x20230427
size*4: 0x1fdc0 (130496)
txt_svn: 0x00000004
se_svn: 0x0000000b
code_control: 0x0
entry point: 0x00000008:0000da16
scratch_size: 0xd0 (208)
info_table:
uuid: {0x7fc03aaa, 0x46a7, 0x18db, 0xac2e,
{0x69, 0x8f, 0x8d, 0x41, 0x7f, 0x5a}}
ACM_UUID_V3
chipset_acm_type: 0x1 (SINIT)
version: 7
length: 0x30 (48)
chipset_id_list: 0x6f0
os_sinit_data_ver: 0x7
min_mle_hdr_ver: 0x00020000
capabilities: 0x0000077e
rlp_wake_getsec: 0
rlp_wake_monitor: 1
ecx_pgtbl: 1
stm: 1
pcr_map_no_legacy: 1
pcr_map_da: 1
platform_type: 1
max_phy_addr: 1
tcg_event_log_format: 1
cbnt_supported: 1
acm_ver: 39
acm_revision: 1.12.10
chipset list:
count: 3
entry 0:
flags: 0x1
vendor_id: 0x8086
device_id: 0xb00f
revision_id: 0x1
extended_id: 0x0
entry 1:
flags: 0x1
vendor_id: 0x8086
device_id: 0xb012
revision_id: 0x1
extended_id: 0x0
entry 2:
flags: 0x1
vendor_id: 0x8086
device_id: 0xb00c
revision_id: 0x1
extended_id: 0x0
processor list:
count: 6
entry 0:
fms: 0x90670
fms_mask: 0xfff3ff0
platform_id: 0x0
platform_mask: 0x0
entry 1:
fms: 0x906a0
fms_mask: 0xfff3ff0
platform_id: 0x0
platform_mask: 0x0
entry 2:
fms: 0xb0670
fms_mask: 0xfff3ff0
platform_id: 0x0
platform_mask: 0x0
entry 3:
fms: 0xb06a0
fms_mask: 0xfff3ff0
platform_id: 0x0
platform_mask: 0x0
entry 4:
fms: 0xb06e0
fms_mask: 0xfff3ff0
platform_id: 0x0
platform_mask: 0x0
entry 5:
fms: 0xb06f0
fms_mask: 0xfff3ff0
platform_id: 0x0
platform_mask: 0x0
TPM info list:
TPM capability:
ext_policy: 0x3
tpm_family : 0x3
tpm_nv_index_set : 0x1
alg count: 4
alg_id: 0x4
alg_id: 0xb
alg_id: 0xc
alg_id: 0x16
signature information:
key size*4: 0x60 (96)
RSA public key:
59 4b a3 88 70 7c 03 8f 23 5d d1 02 f8 93 25 78
ed 3f b4 f9 cf 67 e1 f9 7f c6 68 4e d1 08 c5 9d
7e 09 8e 9d 05 f4 e1 ad 1b 7c db 86 6d 87 a9 88
13 5c 47 a1 45 dd 11 4e 73 5c 0b dd 07 2f 07 d7
3d be e9 eb 4a a4 34 f3 a5 f2 ff 2c df 9c 8a dc
39 1f ac b0 96 30 48 ae 85 8c 81 c9 cf 68 6f dc
86 56 93 6c 59 c2 9d ff 0b 3b 87 59 af 1b d5 8d
9d 84 a2 2f d6 ad d6 49 8a 1a 5c d2 a6 df 98 f5
25 48 7f b1 62 0f dd 9d 89 9f ea 0a 65 c3 c7 26
9c 87 00 7c 6c 0a 04 90 5d 9b 1a 1c d5 36 fa d6
c9 d1 2a d9 e6 93 0f 5e 5f 42 8b 75 98 f9 7d f8
47 2e a8 71 1c d2 b9 58 a0 75 7d 7e 81 0c d7 3f
cc e8 a2 f2 e2 87 76 aa 60 ea 8c 47 7a 74 84 33
a4 49 60 e8 4b 7f b9 27 e9 cd 35 5f c0 ed a1 5f
34 31 b0 be 66 90 94 72 e5 3c 5f be 7f 1f ea 32
14 d9 c6 2b b8 c3 91 12 ba 34 ae 21 0b 21 c9 25
0d 7f b7 e5 4e f4 75 b3 f4 2f 2a c9 9d 18 dd 18
55 84 a0 f0 b6 91 f9 11 11 a1 bb b3 1e 38 75 15
67 33 ca 16 46 a8 77 22 2b b1 8f c8 29 bc ed f1
82 de 20 af a9 2f ec 4e dd 31 15 25 6b 20 35 24
19 f7 83 5a 2b e9 2e 43 85 a2 fb 5e 2e 8f cc bb
85 81 ac 73 53 1a 25 4c 77 13 76 0e e0 82 b6 f8
ae d8 eb 79 aa b9 cc 67 d8 54 7b 9b d0 de 06 06
77 70 c7 ee 73 31 d7 96 5a 1a 29 33 e3 a6 30 a8
RSA public key exponent: 0xe5b77f0d
PKCS #1.5 RSA signature:
4e f4 75 b3 f4 2f 2a c9 9d 18 dd 18 55 84 a0 f0
b6 91 f9 11 11 a1 bb b3 1e 38 75 15 67 33 ca 16
46 a8 77 22 2b b1 8f c8 29 bc ed f1 82 de 20 af
a9 2f ec 4e dd 31 15 25 6b 20 35 24 19 f7 83 5a
2b e9 2e 43 85 a2 fb 5e 2e 8f cc bb 85 81 ac 73
53 1a 25 4c 77 13 76 0e e0 82 b6 f8 ae d8 eb 79
aa b9 cc 67 d8 54 7b 9b d0 de 06 06 77 70 c7 ee
73 31 d7 96 5a 1a 29 33 e3 a6 30 a8 c6 71 12 5c
21 42 69 3c 20 66 81 8a 60 63 f5 d0 b7 25 ce 9e
9f 01 12 fa cb 29 7c 7e 96 40 c9 5f a6 c8 ec 4e
12 92 ab a8 0c b5 1a fc 2f f3 6a 93 17 e1 d0 e2
0d d1 01 9a bc e9 9a 82 0e 9a aa 90 f4 62 eb 6d
e5 e6 c0 c0 63 f5 17 c7 9b f6 2f ce 75 d7 61 69
80 7a 34 bc 34 ca 47 9e 55 7a d5 97 30 34 fb 79
20 a7 b6 3a 2a 8b c3 66 3e a8 23 56 62 b9 f2 60
7b 28 55 37 38 6f 5b 06 22 ee a9 26 5f 26 b7 dd
ERROR: No TXT heap is available
TBOOT log:
max_size=65474
zip_count=0
curr_pos=11505
buf:
TBOOT: *********************** TBOOT ***********************
TBOOT: 2024-10-11 12:00 +0100 1.11.9
TBOOT: *****************************************************
TBOOT: This tboot version supports TPR.
TBOOT: This tboot version tries to move SINIT in ldr_ctx v3.
TBOOT: This tboot version disables DMA remapping.
TBOOT: command line: pcr_map=da loglvl=all serial=115200,8n1,0x2f8 logging=serial,memory
TBOOT: IA32_FEATURE_CONTROL_MSR: 0000ff07
TBOOT: CPU is SMX-capable
TBOOT: CPU is VMX-capable
TBOOT: SMX is enabled
TBOOT: TXT chipset and all needed capabilities present
TBOOT: Loader context at: 0x853c48
TBOOT: MB2 dump: addr 0x22000, size 4264
TBOOT: MB2 tag found of type 21 size 12
TBOOT: MB2 tag found of type 1 size 76 pcr_map=da loglvl=all serial=115200,8n1,0x2f8 logging=serial,memory
TBOOT: MB2 tag found of type 2 size 18 GRUB 2.12
TBOOT: MB2 tag found of type 3 size 45 mod_start: 0x5495000, mod_end: 0x5e9f400 root=/dev/nvme0n1p2 ro noefi
TBOOT:
TBOOT: MB2 tag found of type 3 size 17 mod_start: 0x1000, mod_end: 0x137d
TBOOT: MB2 tag found of type 3 size 17 mod_start: 0x2000, mod_end: 0x21dc0
TBOOT: MB2 tag found of type 6 size 544
TBOOT: MB2 tag found of type 4 size 16
TBOOT: MB2 tag found of type 12 size 16
TBOOT: MB2 tag found of type 14 size 28
TBOOT: MB2 tag found of type 15 size 44
TBOOT: MB2 tag found of type 17 size 3376
TBOOT: MB2 tag found of type 0 size 8
TBOOT: IA32_FEATURE_CONTROL_MSR: 0000ff07
TBOOT: CPU is SMX-capable
TBOOT: CPU is VMX-capable
TBOOT: SMX is enabled
TBOOT: TXT chipset and all needed capabilities present
TBOOT: move modules above tboot.
TBOOT: Highest mod end: 0x5e9f400
TBOOT: Initial mod destination: 0x5ea0000
TBOOT: TBOOT memory end: 0x5495000
TBOOT: 0x7ff000 bytes copied from 0x1000 to 0x5ea0000
TBOOT: loader context was moved from 0x22000 to 0x5ec1000
TBOOT: Loader context after moving modules0x853c48
TBOOT: MB2 dump: addr 0x5ec1000, size 4264
TBOOT: MB2 tag found of type 21 size 12
TBOOT: MB2 tag found of type 1 size 76 pcr_map=da loglvl=all serial=115200,8n1,0x2f8 logging=serial,memory
TBOOT: MB2 tag found of type 2 size 18 GRUB 2.12
TBOOT: MB2 tag found of type 3 size 45 mod_start: 0x5495000, mod_end: 0x5e9f400 root=/dev/nvme0n1p2 ro noefi
TBOOT:
TBOOT: MB2 tag found of type 3 size 17 mod_start: 0x5ea0000, mod_end: 0x5ea037d
TBOOT: MB2 tag found of type 3 size 17 mod_start: 0x5ea1000, mod_end: 0x5ec0dc0
TBOOT: MB2 tag found of type 6 size 544
TBOOT: MB2 tag found of type 4 size 16
TBOOT: MB2 tag found of type 12 size 16
TBOOT: MB2 tag found of type 14 size 28
TBOOT: MB2 tag found of type 15 size 44
TBOOT: MB2 tag found of type 17 size 3376
TBOOT: MB2 tag found of type 0 size 8
TBOOT: IA32_FEATURE_CONTROL_MSR: 0000ff07
TBOOT: CPU is SMX-capable
TBOOT: CPU is VMX-capable
TBOOT: SMX is enabled
TBOOT: TXT chipset and all needed capabilities present
TBOOT: BSP is cpu 0
TBOOT: Original EFI memory map:
TBOOT: 0000000000000000 - 0000000000025000 (2 | 0xf | EFI_LOADER_DATA)
TBOOT: 0000000000025000 - 000000000009e000 (7 | 0xf | EFI_CONVENTIONAL_MEMORY)
TBOOT: 000000000009e000 - 000000000009f000 (0 | 0xf | EFI_RESERVED_TYPE)
TBOOT: 000000000009f000 - 00000000000a0000 (4 | 0xf | EFI_BOOT_SERVICES_DATA)
TBOOT: 0000000000100000 - 0000000000800000 (7 | 0xf | EFI_CONVENTIONAL_MEMORY)
TBOOT: 0000000000800000 - 0000000005ea0000 (2 | 0xf | EFI_LOADER_DATA)
TBOOT: 0000000005ea0000 - 0000000063961000 (7 | 0xf | EFI_CONVENTIONAL_MEMORY)
TBOOT: 0000000063961000 - 0000000065961000 (1 | 0xf | EFI_LOADER_CODE)
TBOOT: 0000000065961000 - 00000000659e1000 (4 | 0xf | EFI_BOOT_SERVICES_DATA)
TBOOT: 00000000659e1000 - 000000006bdd0000 (7 | 0xf | EFI_CONVENTIONAL_MEMORY)
TBOOT: 000000006bdd0000 - 000000006bdf4000 (1 | 0xf | EFI_LOADER_CODE)
TBOOT: 000000006bdf4000 - 000000006be11000 (7 | 0xf | EFI_CONVENTIONAL_MEMORY)
TBOOT: 000000006be11000 - 000000006be12000 (4 | 0xf | EFI_BOOT_SERVICES_DATA)
TBOOT: 000000006be12000 - 000000006be13000 (2 | 0xf | EFI_LOADER_DATA)
TBOOT: 000000006be13000 - 000000006be19000 (7 | 0xf | EFI_CONVENTIONAL_MEMORY)
TBOOT: 000000006be19000 - 000000006d7b0000 (4 | 0xf | EFI_BOOT_SERVICES_DATA)
TBOOT: 000000006d7b0000 - 000000006d7cb000 (3 | 0xf | EFI_BOOT_SERVICES_CODE)
TBOOT: 000000006d7cb000 - 000000006d7f6000 (4 | 0xf | EFI_BOOT_SERVICES_DATA)
TBOOT: 000000006d7f6000 - 000000006d7f8000 (3 | 0xf | EFI_BOOT_SERVICES_CODE)
TBOOT: 000000006d7f8000 - 000000006d7fd000 (4 | 0xf | EFI_BOOT_SERVICES_DATA)
TBOOT: 000000006d7fd000 - 000000006d7ff000 (3 | 0xf | EFI_BOOT_SERVICES_CODE)
TBOOT: 000000006d7ff000 - 000000006d804000 (4 | 0xf | EFI_BOOT_SERVICES_DATA)
TBOOT: 000000006d804000 - 000000006d808000 (3 | 0xf | EFI_BOOT_SERVICES_CODE)
TBOOT: 000000006d808000 - 000000006d810000 (4 | 0xf | EFI_BOOT_SERVICES_DATA)
TBOOT: 000000006d810000 - 000000006d812000 (3 | 0xf | EFI_BOOT_SERVICES_CODE)
TBOOT: 000000006d812000 - 000000006d818000 (4 | 0xf | EFI_BOOT_SERVICES_DATA)
TBOOT: 000000006d818000 - 000000006d819000 (3 | 0xf | EFI_BOOT_SERVICES_CODE)
TBOOT: 000000006d819000 - 000000006d830000 (4 | 0xf | EFI_BOOT_SERVICES_DATA)
TBOOT: 000000006d830000 - 000000006d834000 (3 | 0xf | EFI_BOOT_SERVICES_CODE)
TBOOT: 000000006d834000 - 000000006d83c000 (4 | 0xf | EFI_BOOT_SERVICES_DATA)
TBOOT: 000000006d83c000 - 000000006d844000 (3 | 0xf | EFI_BOOT_SERVICES_CODE)
TBOOT: 000000006d844000 - 000000006d85c000 (4 | 0xf | EFI_BOOT_SERVICES_DATA)
TBOOT: 000000006d85c000 - 000000006d862000 (3 | 0xf | EFI_BOOT_SERVICES_CODE)
TBOOT: 000000006d862000 - 000000006d872000 (4 | 0xf | EFI_BOOT_SERVICES_DATA)
TBOOT: 000000006d872000 - 000000006d8be000 (3 | 0xf | EFI_BOOT_SERVICES_CODE)
TBOOT: 000000006d8be000 - 000000006d901000 (4 | 0xf | EFI_BOOT_SERVICES_DATA)
TBOOT: 000000006d901000 - 000000006d904000 (3 | 0xf | EFI_BOOT_SERVICES_CODE)
TBOOT: 000000006d904000 - 000000006d9d9000 (4 | 0xf | EFI_BOOT_SERVICES_DATA)
TBOOT: 000000006d9d9000 - 000000006d9e0000 (3 | 0xf | EFI_BOOT_SERVICES_CODE)
TBOOT: 000000006d9e0000 - 000000006d9eb000 (4 | 0xf | EFI_BOOT_SERVICES_DATA)
TBOOT: 000000006d9eb000 - 000000006d9f0000 (3 | 0xf | EFI_BOOT_SERVICES_CODE)
TBOOT: 000000006d9f0000 - 000000006d9f9000 (4 | 0xf | EFI_BOOT_SERVICES_DATA)
TBOOT: 000000006d9f9000 - 000000006da36000 (3 | 0xf | EFI_BOOT_SERVICES_CODE)
TBOOT: 000000006da36000 - 000000006e922000 (4 | 0xf | EFI_BOOT_SERVICES_DATA)
TBOOT: 000000006e922000 - 000000006e939000 (3 | 0xf | EFI_BOOT_SERVICES_CODE)
TBOOT: 000000006e939000 - 000000006e949000 (4 | 0xf | EFI_BOOT_SERVICES_DATA)
TBOOT: 000000006e949000 - 000000006e951000 (3 | 0xf | EFI_BOOT_SERVICES_CODE)
TBOOT: 000000006e951000 - 0000000071360000 (4 | 0xf | EFI_BOOT_SERVICES_DATA)
TBOOT: 0000000071360000 - 000000007162c000 (7 | 0xf | EFI_CONVENTIONAL_MEMORY)
TBOOT: 000000007162c000 - 0000000072155000 (3 | 0xf | EFI_BOOT_SERVICES_CODE)
TBOOT: 0000000072155000 - 0000000075255000 (0 | 0xf | EFI_RESERVED_TYPE)
TBOOT: 0000000075255000 - 000000007536f000 (9 | 0xf | EFI_ACPI_RECLAIM_MEMORY)
TBOOT: 000000007536f000 - 000000007544c000 (10 | 0xf | EFI_ACPI_MEMORY_NVS)
TBOOT: 000000007544c000 - 0000000075f66000 (6 | 0x800000000000000f | EFI_RUNTIME_SERVICES_DATA)
TBOOT: 0000000075f66000 - 0000000075fff000 (5 | 0x800000000000000f | EFI_RUNTIME_SERVICES_CODE)
TBOOT: 0000000075fff000 - 0000000076000000 (4 | 0xf | EFI_BOOT_SERVICES_DATA)
TBOOT: 0000000100000000 - 000000107fc00000 (7 | 0xf | EFI_CONVENTIONAL_MEMORY)
TBOOT: 00000000000a0000 - 0000000000100000 (0 | 0x0 | EFI_RESERVED_TYPE)
TBOOT: 0000000076000000 - 000000007a000000 (0 | 0xf | EFI_RESERVED_TYPE)
TBOOT: 000000007a600000 - 000000007a800000 (0 | 0xf | EFI_RESERVED_TYPE)
TBOOT: 000000007ac00000 - 000000007b000000 (0 | 0x0 | EFI_RESERVED_TYPE)
TBOOT: 000000007b000000 - 000000007c000000 (0 | 0x9 | EFI_RESERVED_TYPE)
TBOOT: 000000007c000000 - 0000000080400000 (0 | 0x0 | EFI_RESERVED_TYPE)
TBOOT: 00000000c0000000 - 00000000d0000000 (11 | 0x8000000000000001 | EFI_MEMORY_MAPPED_IO)
TBOOT: 00000000fe000000 - 00000000fe011000 (11 | 0x8000000000000001 | EFI_MEMORY_MAPPED_IO)
TBOOT: 00000000fec00000 - 00000000fec01000 (11 | 0x8000000000000001 | EFI_MEMORY_MAPPED_IO)
TBOOT: 00000000fed00000 - 00000000fed01000 (11 | 0x8000000000000001 | EFI_MEMORY_MAPPED_IO)
TBOOT: 00000000fed20000 - 00000000fed80000 (0 | 0x0 | EFI_RESERVED_TYPE)
TBOOT: 00000000fee00000 - 00000000fee01000 (11 | 0x8000000000000001 | EFI_MEMORY_MAPPED_IO)
TBOOT: 00000000ff000000 - 0000000100000000 (11 | 0x800000000000100d | EFI_MEMORY_MAPPED_IO)
TBOOT: Original E820 memory map:
TBOOT: 0000000000000000 - 000000000009e000 (1 - E820_RAM)
TBOOT: 000000000009e000 - 000000000009f000 (2 - E820_RESERVED)
TBOOT: 000000000009f000 - 00000000000a0000 (1 - E820_RAM)
TBOOT: 00000000000a0000 - 0000000000100000 (2 - E820_RESERVED)
TBOOT: 0000000000100000 - 0000000072155000 (1 - E820_RAM)
TBOOT: 0000000072155000 - 0000000075255000 (2 - E820_RESERVED)
TBOOT: 0000000075255000 - 000000007536f000 (3 - E820_ACPI)
TBOOT: 000000007536f000 - 000000007544c000 (4 - E820_NVS)
TBOOT: 000000007544c000 - 0000000075f66000 (2 - E820_RESERVED)
TBOOT: 0000000075f66000 - 0000000075fff000 (20 - unknown type)
TBOOT: 0000000075fff000 - 0000000076000000 (1 - E820_RAM)
TBOOT: 0000000076000000 - 000000007a000000 (2 - E820_RESERVED)
TBOOT: 000000007a600000 - 000000007a800000 (2 - E820_RESERVED)
TBOOT: 000000007ac00000 - 0000000080400000 (2 - E820_RESERVED)
TBOOT: 00000000c0000000 - 00000000d0000000 (2 - E820_RESERVED)
TBOOT: 00000000fe000000 - 00000000fe011000 (2 - E820_RESERVED)
TBOOT: 00000000fec00000 - 00000000fec01000 (2 - E820_RESERVED)
TBOOT: 00000000fed00000 - 00000000fed01000 (2 - E820_RESERVED)
TBOOT: 00000000fed20000 - 00000000fed80000 (2 - E820_RESERVED)
TBOOT: 00000000fee00000 - 00000000fee01000 (2 - E820_RESERVED)
TBOOT: 00000000ff000000 - 0000000100000000 (2 - E820_RESERVED)
TBOOT: 0000000100000000 - 000000107fc00000 (1 - E820_RAM)
TBOOT: checking if module is an SINIT for this platform...
TBOOT: chipset production fused: 1
TBOOT: chipset ids: vendor: 0x8086, device: 0xb00c, revision: 0x1
TBOOT: processor family/model/stepping: 0x906a4
TBOOT: platform id: 0x1c000000000000
TBOOT: 3 ACM chipset id entries:
TBOOT: vendor: 0x8086, device: 0xb00f, flags: 0x1, revision: 0x1, extended: 0x0
TBOOT: vendor: 0x8086, device: 0xb012, flags: 0x1, revision: 0x1, extended: 0x0
TBOOT: vendor: 0x8086, device: 0xb00c, flags: 0x1, revision: 0x1, extended: 0x0
TBOOT: 6 ACM processor id entries:
TBOOT: fms: 0x90670, fms_mask: 0xfff3ff0, platform_id: 0x0, platform_mask: 0x0
TBOOT: fms: 0x906a0, fms_mask: 0xfff3ff0, platform_id: 0x0, platform_mask: 0x0
TBOOT: SINIT matches platform
TBOOT: TXT.SINIT.BASE: 0x0
TBOOT: TXT.SINIT.SIZE: 0x0 (0)
TBOOT: BIOS-reserved SINIT size (0) is too small for loaded SINIT (1fdc0)
TBOOT: SINIT ACM not provided.
TBOOT: reserving tboot memory log (60000 - 6ffff) in e820 table
TBOOT: got sinit match on module #2
TBOOT: v2 LCP policy data found
TBOOT: ELF magic number is not matched, image is not ELF format.
TBOOT: assuming kernel is Linux format
TBOOT: Kernel (protected mode) from 0x6000000 to 0x6a06400
TBOOT: Kernel (real mode) from 0x90000 to 0x94000
TBOOT: Linux cmdline from 0x98d00 to 0x99100:
TBOOT: root=/dev/nvme0n1p2 ro noefi
TBOOT: EFI memmap: memmap base: 0x71808, memmap size: 0xd80
TBOOT: EFI memmap: descr size: 0x30, descr version: 0x1
TBOOT: transfering control to kernel @0x6000000...
|
|
From: Jason A. <jan...@gm...> - 2024-05-12 15:43:13
|
Hi, I wrote this script a while ago. Maybe it'll be useful to someone: https://github.com/jandryuk/tpm-event-log It parses TPM event logs, like the sysfs binary_bios_measurements file from Linux or the tboot TXT tpm20_binary_evtlog_tcg exposed by OpenXT. (You might need to cat sysfs entries into regular files first). It handles TPM 1.2 and 2.0 and predates tpm2_eventlog. The benefit over tpm2_eventlog is that it provides details about some events in the log. Specifically, it'll parse and print UEFI boot paths, so you know what the system was trying to boot. It'll also print out grub commands. tboot itself doesn't provide meaningful details about its events. Printing is not exhaustive. Mainly, it prints details about things I needed more info about. That is to say, it handles things I've seen in actual logs, so there may be gaps. It assumes a well formatted log. Anyway, maybe someone will find it interesting. Regards, Jason |
|
From: Christopher B. <sal...@gm...> - 2024-01-29 16:12:06
|
On 1/29/24 02:31, Florian Weimer wrote:
> As far as I can tell, this warning is both technically correct and
> harmless. The called generate_composite_hash hash function only writes
> SHA1_DIGEST_SIZE bytes and uses byte accesses.
>
> Thanks,
> Florian
>
> diff --git a/lcptools-v2/pconf_legacy.c b/lcptools-v2/pconf_legacy.c
> index 443b5cd5525b9fe1..5ebc6c451f7008b1 100644
> --- a/lcptools-v2/pconf_legacy.c
> +++ b/lcptools-v2/pconf_legacy.c
> @@ -324,7 +324,7 @@ static lcp_policy_element_t *create(void)
> ERROR("Error: no pcrs were selected.\n");
> return NULL;
> }
> - digest = malloc(SHA1_DIGEST_SIZE);
> + digest = malloc(sizeof(*digest));
> if (digest == NULL) {
> ERROR("Error: failed to allocate memory for digest buffer.\n");
> return NULL;
>
>
>
> _______________________________________________
> tboot-devel mailing list
> tbo...@li...
> https://lists.sourceforge.net/lists/listinfo/tboot-devel
That's not the only patch that file needed. When I submitted the
original patch to use the correct algorithm, I missed a line.
|
|
From: Florian W. <fw...@re...> - 2024-01-29 08:32:15
|
As far as I can tell, this warning is both technically correct and
harmless. The called generate_composite_hash hash function only writes
SHA1_DIGEST_SIZE bytes and uses byte accesses.
Thanks,
Florian
diff --git a/lcptools-v2/pconf_legacy.c b/lcptools-v2/pconf_legacy.c
index 443b5cd5525b9fe1..5ebc6c451f7008b1 100644
--- a/lcptools-v2/pconf_legacy.c
+++ b/lcptools-v2/pconf_legacy.c
@@ -324,7 +324,7 @@ static lcp_policy_element_t *create(void)
ERROR("Error: no pcrs were selected.\n");
return NULL;
}
- digest = malloc(SHA1_DIGEST_SIZE);
+ digest = malloc(sizeof(*digest));
if (digest == NULL) {
ERROR("Error: failed to allocate memory for digest buffer.\n");
return NULL;
|
|
From: Timo L. <tim...@ik...> - 2023-12-20 16:10:57
|
Hi,
a Debian 12 installation with tboot stopped working when I upgraded BIOS
from version 2.4.2 to version 2.9.0. Instead of a normal boot the system
just resets and BIOS tells me that
"There was an error during TXT SNIT ACM invocation on the previous boot.
Verify that the SINIT ACM used is compatible with this platform and
with the OS loader."
Here's more info:
Hardware: Dell PowerEdge R420
Boot mode: BIOS
TPM version: 1.2
CPUs: 2 x Intel(R) Xeon(R) CPU E5-2430 0 @ 2.20GHz
tboot package version: 1.10.5-4
intel-acm package version: 20210710-2
The serial console logs are available at the following URLs:
https://lindi.iki.fi/lindi/tboot/Dell_PowerEdge_R420_BIOS_2.4.2_serial.txt
https://lindi.iki.fi/lindi/tboot/Dell_PowerEdge_R420_BIOS_2.9.0_serial.txt
Reverting back to the old BIOS version resolved the issue but I guess this
should be investigated?
-Timo
|
|
From: Heting W. <me...@im...> - 2023-08-16 18:13:15
|
All GRUB configurations generated for tboot misses "rootflags=subvol=root" and causes boot failure:
if [ -z "${kernelopts}" ]; then
set kernelopts="root=UUID=f4131454-9e14-4af9-b28e-93afc232a8b2 ro rootflags=subvol=root rd.luks.uuid=luks-3fc85411-b08c-4185-b41d-bc0950877aeb rhgb quiet "
fi
……
submenu "tboot 1.10.5" {
menuentry 'Fedora GNU/Linux, with tboot 1.10.5 and Linux 6.4.10-100.fc37.x86_64' --class fedora --class gnu-linux --class gnu --class os --class tboot {
insmod multiboot2
insmod part_gpt
insmod ext2
set root='hd1,gpt2'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd1,gpt2 --hint-efi=hd1,gpt2 --hint-baremetal=ahci1,gpt2 85215e34-eff0-4cba-9f44-f9c485483800
else
search --no-floppy --fs-uuid --set=root 85215e34-eff0-4cba-9f44-f9c485483800
fi
echo 'Loading tboot 1.10.5 ...'
multiboot2 /tboot.gz logging=serial,memory,vga
echo 'Loading Linux 6.4.10-100.fc37.x86_64 ...'
module2 /vmlinuz-6.4.10-100.fc37.x86_64 root=UUID=f4131454-9e14-4af9-b28e-93afc232a8b2 ro rd.luks.uuid=luks-3fc85411-b08c-4185-b41d-bc0950877aeb rhgb quiet intel_iommu=on noefi
echo 'Loading initial ramdisk ...'
module2 /initramfs-6.4.10-100.fc37.x86_64.img
echo 'Loading sinit SNB_IVB_SINIT_20190708_PW.bin ...'
module2 /SNB_IVB_SINIT_20190708_PW.bin
}
|
|
From: Matthias G. <mge...@su...> - 2023-05-31 08:40:53
|
Hello list,
a customer is experiencing a regression using tboot in some new
hardware/boot environment. Their boot gets stuck in the call to
move_modules(), producing the following log:
TBOOT: no LCP module found
TBOOT: This is an ELF32 file.
TBOOT: kernel is ELF format
TBOOT: 0x6ff000 bytes copied from 0x101000 to 0x364f000
TBOOT: loader context was moved from 0x100130 to 0x364e130
The next logline that should occur "move modules to high memory" never
shows up. An engineer on the customer side identified the likely cause
of this; quote:
> Looks like this is a bug in tboot... in move_modules(), it tries to copy the MBI
> and any modules that are loaded below tboot to memory above tboot--but due to
> faulty logic in an if/then, it is not copying the MBI if its address is below
> tboot & below the lowest module's address.
>
> You can see that with the tboot messages:
>
> TBOOT: 0x6ff000 bytes copied from 0x101000 to 0x3586000
> TBOOT: loader context was moved from 0x100130 to 0x3585130
>
> The loader context (MBI) was not moved, so when it tries to access it at the new
> location, it may see no modules, or it may get bad info, just depending on what
> happens to me in that memory.
>
> The latest upstream code appears to have this bug, also.
I have attached the suggested patch to this email.
Can you please review the patch and apply it to the repository if the
analysis is correct?
Thanks
Matthias
--
Matthias Gerstner <mat...@su...>
Security Engineer
https://www.suse.com/security
GPG Key ID: 0x14C405C971923553
SUSE Software Solutions Germany GmbH
HRB 36809, AG Nürnberg
Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
|
|
From: Eric Li <lix...@gm...> - 2023-05-09 22:16:29
|
I recently found that in tboot/include/txt/heap.h, os_mle_data_t defines saved_misc_enable_msr with type uint32_t. However, MSRs contain 64 bits, so uint64_t should be used. The consequence of this bug is that in tboot/txt/txt.c, "os_mle_data->saved_misc_enable_msr = rdmsr(MSR_IA32_MISC_ENABLE);" results in integer truncation. On my machine (Dell 7050 with Intel(R) Core(TM) i5-7600 CPU @ 3.50GHz), I see that IA32_MISC_ENABLE before SENTER is 0x4000840089. However, IA32_MISC_ENABLE after SENTER is restored to 0x840089, where the 34th bit is lost. This bug appears in tboot-1.11.1, it also appears in the latest version on sourceforge: https://sourceforge.net/p/tboot/code/ci/20d511/tree/tboot/include/txt/heap.h#l288 Could you please fix this bug in tboot? Thank you. |
|
From: Dr. G. <gr...@en...> - 2023-02-04 06:06:07
|
Good evening, I hope the week has gone well for everyone. On behalf of the Quixote team: Izzy the Golden Retriever, Maria, John and myself; I am pleased to announce the initial release of the Quixote/TSEM Trust Orchestration System. We believe it uniquely positions Linux to demonstrate a new approach to security and security co-processor architectures. Quixote/TSEM is based on the notion, that like all other physical phenomenon, the security state of a platform or workload can be mathematically modeled. The objective is to provide for Linux security what Docker did for Linux namespace technology. There are two major components to this architecture. TSEM is the Trusted Security Event Modeling system. It is a new Linux Security Module implementation, that at a conceptual level, is a blending of integrity measurement and mandatory access controls. It treats the LSM hooks as the basis set for a functional description of the security state of a system. Quixote is the userspace software stack that makes the TSEM LSM useful. It implements the concept of a Trust Orchestration System (TOS). A trust orchestration environment is designed to keep a platform or workload in a known trust state. It thus implements the notion of prospective trust rather than the retrospective trust model available with TPM based architectures. A patch series implementing the TSEM LSM has been submitted to the linux-security-module list for review and inclusion in the upstream kernel. The source code for the Quixote TOS and pre-compiled binaries for the userspace tooling can be found at the following URL: ftp://ftp.enjellic.com/pub/Quixote The source release includes a selection of TMA's that include Xen, SGX and micro-controller implementations. The kernel patches include a documentation file, that we believe, thoroughly discusses the rationale and implementation of the new architecture. To avoid further indemnifying my reputation for loquaciousness in e-mail, I will defer interested parties to that document for further discussion. The document is also included in the Quixote source code release for those who choose to download that. In addition to initiating a discussion on a different approach to security, we hope that this release keeps Casey Schaufler from turning more blue than he already is. Given that I had mentioned to him two months ago that a new LSM would become available, "in a couple of weeks", that may influence conversations on changes to the Linux LSM architecture that are being discussed. Such is the state of software development.... :-) I would be more than happy to field any additional questions that may be forthcoming. Best wishes for a pleasant weekend. As always, Dr. Greg The Quixote Project - Flailing at the Travails of Cybersecurity |
|
From: Randzio, P. <paw...@in...> - 2023-01-25 09:32:51
|
Hi Łukasz, Sorry for not responding to your e-mail earlier, but somehow it failed to reach me through both of my inboxes. Thank you for pointing out that memory overlap issue, I was not aware of this. And as I've mentioned in the new commit message: when I tested it on some of our platforms (Xeons mostly) they didn't have much of an issue with this (somehow), that's why I did not expect anything to come up. The motivation was to unlock the possible length of logs a little bit, because high core count CPUs had only several hundred lines of VMXOFF in them. Now I know that we will need to do it some other way Anyway - thanks for the heads-up and sorry for that mess :) Best regards, Paweł --------------------------------------------------------------------- Intel Technology Poland sp. z o.o. ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII Wydzial Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 957-07-52-316 | Kapital zakladowy 200.000 PLN. Spolka oswiadcza, ze posiada status duzego przedsiebiorcy w rozumieniu ustawy z dnia 8 marca 2013 r. o przeciwdzialaniu nadmiernym opoznieniom w transakcjach handlowych. Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresata i moze zawierac informacje poufne. W razie przypadkowego otrzymania tej wiadomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie; jakiekolwiek przegladanie lub rozpowszechnianie jest zabronione. This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). If you are not the intended recipient, please contact the sender and delete all copies; any review or distribution by others is strictly prohibited. |
|
From: Łukasz H. <lu...@ha...> - 2022-12-27 21:56:22
|
Hi Paweł On Thu, 2022-12-22 at 15:13 +0000, Pawel Randzio wrote: > changeset b06289220ef8 in /hg/p/tboot/code > details: http://hg.code.sf.net/p/tboot/code/code?cmd=changeset;node=b06289220ef8 > description: > Extend low memory range reserved for logs > > Some platforms with higher core count had the issue of logs > overflowing the memory range reserved for them, and thus > overwriting themselves, leaving just a bit of last lines > of logs to be later read. > > Before range was 32KB, now it is 200KB which HOPEFULLY > won't need further extensions > This patch adds at least two memory overlap issues. Real mode part of Linux kernel (and cmdline args) has starting address limited in TBOOT to max 0x90000. After this patch, memory assigned to logs overlaps with this address. In my testing system - i5-7300U, Linux kernel does not start after applying the patch. Secondly, address of TBOOT's S3 wakeup handler is hardcoded to 0x8a000, that also is covered by the new logs region. I am not XEN expert, but there is also a comment in config.h that suggest that XEN has some trampoline code at 0x8c000, this may also conflict with logs. As I said, my testing system does not boot with this patch, I expect that this is not the only one. I don't know the exact motivation on expanding space for logs, but you should consider to do this in another way. Thanks, Lukasz |
|
From: Christopher B. <sal...@gm...> - 2022-12-26 20:08:34
|
This got missed for the current version, so I'm resubmitting for the
next version:
# HG changeset patch
# User Christopher Byrne <sal...@gm...>
# Date 1672084560 21600
# Mon Dec 26 13:56:00 2022 -0600
# Node ID de13f5fe8812350a662e411d5253067a2bb3e3b6
# Parent 4a904a608c70468d3156341dd9132233c4c4ff5b
lcptools-v2/pconf_legacy.c: Add missing BE size_of_pcrs to hash buffer
First fix attempt was almost correct. System still doesn't boot with
PCONF element. I forgot 1 important line though. Once added, the system
now boots with the PCONF element. Tested with both 1 PCR and 2 PCRs.
Signed-of-by: Christopher Byrne <sal...@gm...>
diff -r 4a904a608c70 -r de13f5fe8812 lcptools-v2/pconf_legacy.c
--- a/lcptools-v2/pconf_legacy.c Fri Dec 23 10:15:47 2022 +0100
+++ b/lcptools-v2/pconf_legacy.c Mon Dec 26 13:56:00 2022 -0600
@@ -241,6 +241,7 @@
ERROR("Error: failed to allocate buffer for composite digest.\n");
return false;
}
+ buff->size_of_pcrs = htonl(no_of_pcrs * SHA1_DIGEST_SIZE);
memcpy_s(
&buff->pcr_selection,
sizeof buff->pcr_selection,
|
|
From: Miguel M. <mig...@ua...> - 2022-11-29 18:45:18
|
Hi, Łukasz, First, thanks for the previous answer. It has helped me move forward with remote attestation. While implementing the remote attestation procedure, I attempted to extend the TPM's PCRs further. More precisely, PCR 21 is locked behind locality 2. Therefore only a trusted OS can extend it. However, I can't extend that PCR, even though the txt-stat tool shows the following: "TXT measured launch: TRUE secrets flag set: TRUE ... locality_1_open: TRUE locality_2_open: TRUE " The tpm2_pcrwrite command returns the following error: " tpm:warn(2.0): bad locality " So, from the previous message explanation, I can't write an LCP due to some platform misconfigurations. These configurations don't allow me to write the LCP to the expected NVINDEX. I wrote a VLP instead, which up until this point, was working as expected. Is using a VLP instead of an LCP the reason for not being able to write to locality 2 PCRs? Or is there something else I'm missing on? Best Regards, Miguel Mota ________________________________ De: Łukasz Hawryłko <lu...@ha...> Enviado: 10 de outubro de 2022 10:01 Para: Miguel Mota <mig...@ua...>; tbo...@li... <tbo...@li...> Assunto: Re: [tboot-devel] TBOOT on a PowerEdge R730 with a TPM2.0 Hi Miguel On Fri, 2022-10-07 at 14:30 +0000, Miguel Mota wrote: > If I change either the kernel or the initrd the system still boots as > expected (since I have policy of continue instead of halt) and the > PCR will have different values (as expected) but the TBOOT tool says > the "TXT Measured Launch: True" when I expected it to to be false. Am > I miss-interpreting the normal behaviour of TXT here? Also, is this > VLP (without the LCP) enough for remote attestation? I'd say yes > since pcr 17-20 have all the required information and they can't be > altered by an bad actor due to their locality requirements. "TXT Measured Launch: True" means that system was successfully booted with TXT. Measured launch is a process where measures of boot components are collected and stored to TPM PCRs, but not verified. This is the standard behaviour of TXT. For remote attestation you don't have to provision LCP or VLP, because default policies already collect measurements. You can use LCP or VLP to configure what PCRs will be extended with particular boot components, but in general this is not required. To sum up, you are right, your system is ready to enable remote attestation. Thanks, Lukasz |
|
From: Łukasz H. <lu...@ha...> - 2022-10-10 09:26:46
|
Hi Miguel On Fri, 2022-10-07 at 14:30 +0000, Miguel Mota wrote: > If I change either the kernel or the initrd the system still boots as > expected (since I have policy of continue instead of halt) and the > PCR will have different values (as expected) but the TBOOT tool says > the "TXT Measured Launch: True" when I expected it to to be false. Am > I miss-interpreting the normal behaviour of TXT here? Also, is this > VLP (without the LCP) enough for remote attestation? I'd say yes > since pcr 17-20 have all the required information and they can't be > altered by an bad actor due to their locality requirements. "TXT Measured Launch: True" means that system was successfully booted with TXT. Measured launch is a process where measures of boot components are collected and stored to TPM PCRs, but not verified. This is the standard behaviour of TXT. For remote attestation you don't have to provision LCP or VLP, because default policies already collect measurements. You can use LCP or VLP to configure what PCRs will be extended with particular boot components, but in general this is not required. To sum up, you are right, your system is ready to enable remote attestation. Thanks, Lukasz |
|
From: Miguel M. <mig...@ua...> - 2022-10-07 16:02:46
|
Hi, Lately I've been trying to get tboot to work on a Dell PowerEdge R730 with the latest bios (v2.15.0). In v2.15.0 the BIOS and SINIT ACM were updated to v3.1.5_20211209 according to the Dell change log. The machine is equiped with a TPM2.0 and prior to the following tests no actions were taken with it (important for later). So, I installed tboot (v1.9.12) and the default policy worked straight away. First thing that I noticed was that it was looking for a VLP at NVIndex 0x01200001 but didn't show where it was looking for the LCP. From reading the manuals and some other mailing lists (this one for example: https://sourceforge.net/p/tboot/mailman/message/36754984/) and from the information presented by tboot I reached this conclusion: My TPM2.0 NVIndex Set is 0 based on the information below: TBOOT: TPM info list: TBOOT: TPM capability: TBOOT: ext_policy: 0x3 TBOOT: tpm_family : 0x3 TBOOT: tpm_nv_index_set : 0x0 TBOOT: alg count: 3 TBOOT: alg_id: 0x4 TBOOT: alg_id: 0xb TBOOT: alg_id: 0x14 Therefore the relevant TPM2 NVRAM indexes are as follows (also supported by tboot/common/tpm_20.c line 2795-2798): PS: 0x1800001 PO: 0x1400001 AUX: 0x1800003 SGX: 0x1800004 Thus based on this I should write the LCP into nvindex 0x1400001. The problem is that if I check the current capabilities of my TPM2.0 it presents me with this information: tpm2_getcap handles-nv-index - 0x1400001 - 0x1400002 - 0x1C00002 - 0x1C00003 - 0x1C00004 - 0x1C0000A - 0x1C0000B - 0x1C0000C - 0x1C10102 - 0x1C10103 - 0x1C10104 - 0x1C10105 tpm2_nvreadpublic 0x1400001 0x1400001: name: 000be7351a9ff0c7de635f31d6bd6a1d0fe6f123316614138dc3c743c78bf30edb1f hash algorithm: friendly: sha256 value: 0xB attributes: friendly: ppwrite|authwrite|write_stclear|ppread|authread|no_da|written|platformcreate|read_stclear value: 0x54005E2 size: 32 This , as far as my knowledge goes, tells me I can't clear or write to it since it is established by, in this case, Dell. For sanity of mind I also tried the new index (0x1c10106) but it would end up with an error ("An issue is observed in the previous invocation of TXT SINIT Authenticated Code Module (ACM) because the TXT information stored in the TPM chip may be corrupted.") during boot. I confirmed the information presented in the tpm with the tools used for generating (--show --verbose) and nothing was corrupted, so this index is clearly not the one I want. So, what should regarding this issue? Or where should I place the LCP? I'm using the following commands for generating and written the LCP to the TPM. lcp2_mlehash --create --alg sha256 --cmdline "logging=serial,memory" /boot/tboot.gz > mle_hash lcp2_crtpolelt --create --type mle2 --minver 17 --alg sha256 --out mle.elt mle_hash tb_polgen --create --alg sha256 --type continue vl.pol tb_polgen --add --num 0 --pcr 19 --hash image --cmdline "$(</proc/cmdline) intel_iommu=on noefi" --image "/boot/vmlinuz-$(uname -r)" vl.pol tb_polgen --add --num 1 --pcr 20 --hash image --image "/boot/initrd-$(uname -r)" vl.pol lcp2_crtpolelt --create --type custom --out vl.elt --uuid tboot vl.pol lcp2_crtpollist --create --listver 0x300 --out list_unsig.lst mle.elt pcr.elt vl.elt cp list_unsig.lst list_sig.lst lcp2_crtpollist --sign 0x8 --sigalg rsapss --hashalg sha256 --pub pub.pem --priv priv.pem --out list_sig.lst lcp2_crtpol --create --alg sha256 --polver 3.2 --type list --pol list.pol --data list.data list_sig.lst tpm2_nvdefine -s $(( 38 + 32 )) -a 'ownerwrite|policywrite|authread|no_da' 0x01400001 tpm2_nvwrite -i list.pol 0x01400001 sudp cp list.data /boot Since I couldn't find (and hope to find out what is the problem with this mail), instead of writting the LCP I write the VLP (vl.pol) to 0x01200001. The server can reboot and the system will extend, in this specific case, the PCR 19 with the kernel+cmdline and PCR 20 with the initrd+cmdline. If I change either the kernel or the initrd the system still boots as expected (since I have policy of continue instead of halt) and the PCR will have different values (as expected) but the TBOOT tool says the "TXT Measured Launch: True" when I expected it to to be false. Am I miss-interpreting the normal behaviour of TXT here? Also, is this VLP (without the LCP) enough for remote attestation? I'd say yes since pcr 17-20 have all the required information and they can't be altered by an bad actor due to their locality requirements. |
|
From: Łukasz H. <lu...@ha...> - 2022-07-13 20:46:35
|
Hi Alex
On Mon, 2022-07-11 at 13:00 -0500, Alex Olson wrote:
> # HG changeset patch
> # User Alex Olson <ale...@st...>
> # Date 1657558891 18000
> # Mon Jul 11 12:01:31 2022 -0500
> # Node ID 0552b7ac10e28b378dd139e5ca3838039c472827
> # Parent fa60b63892e8f9d4278950b44ed136d2b12d19cc
> Correct IDT exception handler addresses
>
> The exception handlers configured in the IDT weren't properly executed
> during exceptions as _start/TBOOT_START are not 64K aligned (0x804000).
>
> This revision corrects the arithmetic so that the "int_handler" routine
> gets properly executed instead of "int_handler - 0x4000".
>
> NOTE: A simple way to test this is to insert 'asm volatile("ud2");' in begin_launch().
>
Thank you for the patch.
Lukasz
|
|
From: Alex O. <thi...@gm...> - 2022-07-11 18:00:35
|
# HG changeset patch
# User Alex Olson <ale...@st...>
# Date 1657558891 18000
# Mon Jul 11 12:01:31 2022 -0500
# Node ID 0552b7ac10e28b378dd139e5ca3838039c472827
# Parent fa60b63892e8f9d4278950b44ed136d2b12d19cc
Correct IDT exception handler addresses
The exception handlers configured in the IDT weren't properly executed
during exceptions as _start/TBOOT_START are not 64K aligned (0x804000).
This revision corrects the arithmetic so that the "int_handler" routine
gets properly executed instead of "int_handler - 0x4000".
NOTE: A simple way to test this is to insert 'asm volatile("ud2");' in begin_launch().
Signed-off-by: Alex Olson <ale...@st...>
diff -r fa60b63892e8 -r 0552b7ac10e2 tboot/common/boot.S
--- a/tboot/common/boot.S Fri Jun 17 11:39:11 2022 +0300
+++ b/tboot/common/boot.S Mon Jul 11 12:01:31 2022 -0500
@@ -400,23 +400,28 @@
.align 8
+/* Below assumes "_start" is exactly at TBOOT_START and is needed to allow arithmetic: */
+#define INT_HANDLER_ADDR (int_handler - _start + TBOOT_START)
+#define INT_HANDLER_LO16 (INT_HANDLER_ADDR & 0xffff)
+#define INT_HANDLER_HI16 (INT_HANDLER_ADDR >> 16)
+
idt_table:
.rept 18
- .word int_handler - _start
+ .word INT_HANDLER_LO16
.word cs_sel
.word 0x8e00 /* present, DPL=0, 32b, interrupt */
- .word (int_handler - _start + TBOOT_START) >> 16
+ .word INT_HANDLER_HI16
.endr
/* for machine-check exception */
- .word int_handler - _start
+ .word INT_HANDLER_LO16
.word cs_sel
.word 0x8f00 /* present, DPL=0, 32b, trap */
- .word (int_handler - _start + TBOOT_START) >> 16
+ .word INT_HANDLER_HI16
.rept 237
- .word int_handler - _start
+ .word INT_HANDLER_LO16
.word cs_sel
.word 0x8e00 /* present, DPL=0, 32b, interrupt */
- .word (int_handler - _start + TBOOT_START) >> 16
+ .word INT_HANDLER_HI16
.endr
idt_table_end:
|
|
From: Timo L. <tim...@ik...> - 2022-06-19 21:19:44
|
Hi, please consider the attached patch. Currently tboot respects CFLAGS and LDFLAGS from the environment but not CPPFLAGS. -Timo |
|
From: Timo L. <tim...@ik...> - 2022-06-19 21:17:37
|
Hi,
please consider the attached patch to help make tboot builds reproducible.
Currently using -Werror -Wdate-time causes the build to fail.
The option -Wdate-time is described as:
"Warn when macros __TIME__, __DATE__ or __TIMESTAMP__ are encountered
as they might prevent bit-wise-identical reproducible compilations."
-Timo
|
|
From: Tony C. <tc...@re...> - 2022-06-18 14:36:33
|
On 6/18/2022 8:08 AM, lukasz hawrylko wrote: > Re: [PATCH] 20_linux_tboot: efi logic was inverted > 'noefi' flag tells the kernel that even if current system is EFI based > it must not use EFI services (to be precisely EFI Runtime Services). > This is required because EFI is not a part of TXT TCB. After system > enters TXT environment it must execute only the code that is measured. > As EFI (and BIOS in general) is not measured from TXT perspective you > are not allowed to use it. That's why 'noefi' flag is added. > > Logic is correct in the original version. When EFI capable system is > detected it adds 'noefi' flag to prevent kernel from using EFI. On > non-EFI systems this flag is pointless because kernel can't use EFI > services if they do not exist. > > If removing 'noefi' flag solves your issue, you should find out why. > Maybe there is some information that kernel retrieves from EFI Runtime > Services that is required to properly boot the platform. If this is the > case, the only way to fix this correctly is to get this information in > tboot, before GETSEC[SENTER], and that in some way pass it to the > kernel. You are correct. The chain of trust does not include the EFI runtime. The system having the problem was using VROC. Intel confirms that VROC cannot operate without EFI. They also confirmed the logical conclusion that tboot and VROC are incompatible. So, this is not a bug. |
|
From: Łukasz H. <lu...@ha...> - 2022-06-17 21:45:27
|
Hi Tony
On Thu, 2022-06-09 at 15:04 -0400, Tony Camuso wrote:
> # HG changeset patch
> # User Tony Camuso <tc...@re...>
> # Date 1654800659 14400
> # Thu Jun 09 14:50:59 2022 -0400
> # Node ID be868f53407d4460491a0e77e5165025153b0329
> # Parent 206a47f3e9d2c18c8a3db082216ee6fc3c5d475c
> 20_linux_tboot: efi logic was inverted
>
> There was a RAID0 system that could boot normally, but not through
> a tboot launch. The problem was that the logic in this script
> incorrectly appended 'noefi' to the grub.cfg module2 kernel stanza.
>
> When 'noefi' was removed from that stanza, the system could boot
> through a tboot launch. This patch corrects the logic in the script.
>
> diff -r 206a47f3e9d2 -r be868f53407d tboot/20_linux_tboot
> --- a/tboot/20_linux_tboot Thu Mar 17 23:58:50 2022 +0200
> +++ b/tboot/20_linux_tboot Thu Jun 09 14:50:59 2022 -0400
> @@ -105,11 +105,11 @@
> if [ -d /sys/firmware/efi ] ; then
> mb_directive="multiboot2"
> mb_mod_directive="module2"
> - mb_extra_kernel="noefi"
> + mb_extra_kernel=""
> else
> mb_directive="multiboot2"
> mb_mod_directive="module2"
> - mb_extra_kernel=""
> + mb_extra_kernel="noefi"
> fi
>
> printf "menuentry '${title}' ${CLASS} {\n" "${os}" "${tboot_version}" "${version}"
>
'noefi' flag tells the kernel that even if current system is EFI based
it must not use EFI services (to be precisely EFI Runtime Services).
This is required because EFI is not a part of TXT TCB. After system
enters TXT environment it must execute only the code that is measured.
As EFI (and BIOS in general) is not measured from TXT perspective you
are not allowed to use it. That's why 'noefi' flag is added.
Logic is correct in the original version. When EFI capable system is
detected it adds 'noefi' flag to prevent kernel from using EFI. On
non-EFI systems this flag is pointless because kernel can't use EFI
services if they do not exist.
If removing 'noefi' flag solves your issue, you should find out why.
Maybe there is some information that kernel retrieves from EFI Runtime
Services that is required to properly boot the platform. If this is the
case, the only way to fix this correctly is to get this information in
tboot, before GETSEC[SENTER], and that in some way pass it to the
kernel.
Thanks,
Lukasz
|
|
From: Timo L. <tim...@ik...> - 2022-06-14 07:41:34
|
Hi, that's good to hear, thanks for the quick reply. Would it be possible to include the license text in the zip file in the future? It is difficult to get this through review if the license is not included. Also, how can I know when a new version is available? I don't have a login to the Intel site. Alternatively, would it be possible to have the ACMs available in a more public website like https://www.intel.com/content/www/us/en/developer/articles/tool/intel-trusted-execution-technology.html that already requires users to read the license before downloading? -Timo On Mon, 13 Jun 2022, Bhungal, Jeevan S wrote: > Hi Timo, > > It is the same license, so no change. > > > Jeevan Bhungal > Client Security Technologist | CCG-CPE-CCE > CCE Security Champion > D 916.377.1013 | M 530.844.0930 > Intel Corporation | intel.com > > -----Original Message----- > From: Timo Lindfors <tim...@ik...> > Sent: Monday, June 13, 2022 1:13 AM > To: Jason Andryuk <jan...@gm...> > Cc: Bhungal, Jeevan S <jee...@in...>; Gupta, Rahul Kumar <rah...@in...>; Fedko, Artem <art...@in...>; Crain, Keegan <kee...@in...>; Parmeter, Ben <ben...@in...>; tbo...@li...; Sehra, Supreeti <sup...@in...> > Subject: Re: [tboot-devel] 11th Gen SINIT ACM > > Hi, > > On Mon, 25 Apr 2022, Jason Andryuk wrote: >>> >>> https://cdrdv2.intel.com/v1/dl/getContent/630744?explicitVersion=true >>> >>> Jeevan Bhungal >> >> Great! Yeah, the internal link does not work, but the direct link >> does. Thank you, Jeevan. > > The direct link works but does not seem to contain any license information, just a PDF that says > > "No license (express or implied, by estoppel or otherwise) to any > intellectual property rights is granted by this document." > > I'd like to include these in the Debian non-free package intel-acm. This package currently holds ACM modules published at > > https://www.intel.com/content/www/us/en/developer/articles/tool/intel-trusted-execution-technology.html > > under the following license: > > """ > Copyright (c) 2007 - 2011, Intel(R) Corporation. > All rights reserved. > Redistribution > Redistribution and use in binary form, without modification, are permitted provided that the following conditions are met: > > Redistributions must reproduce the above copyright notice and the following disclaimer in the documentation and/or other materials provided with the distribution. > Neither the name of Intel Corporation nor the names of its suppliers may be used to endorse or promote products derived from this software without specific prior written permission. > No reverse engineering, decompilation, or disassembly of this software is permitted. > > Limited patent license > Intel Corporation grants a world-wide, royalty-free, non-exclusive license under patents it now or hereafter owns or controls to make, have made, use, import, offer to sell and sell ("Utilize") this software, but solely to the extent that any such patent is necessary to Utilize the software alone. The patent license shall not apply to any combinations which include this software. No hardware per se is licensed hereunder. > DISCLAIMER > THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. > > """ > > Is Intel licensing these new files also under the same license or has the license changed? > > > -Timo > > |
|
From: Bhungal, J. S <jee...@in...> - 2022-06-13 18:11:42
|
Hi Timo, It is the same license, so no change. Jeevan Bhungal Client Security Technologist | CCG-CPE-CCE CCE Security Champion D 916.377.1013 | M 530.844.0930 Intel Corporation | intel.com -----Original Message----- From: Timo Lindfors <tim...@ik...> Sent: Monday, June 13, 2022 1:13 AM To: Jason Andryuk <jan...@gm...> Cc: Bhungal, Jeevan S <jee...@in...>; Gupta, Rahul Kumar <rah...@in...>; Fedko, Artem <art...@in...>; Crain, Keegan <kee...@in...>; Parmeter, Ben <ben...@in...>; tbo...@li...; Sehra, Supreeti <sup...@in...> Subject: Re: [tboot-devel] 11th Gen SINIT ACM Hi, On Mon, 25 Apr 2022, Jason Andryuk wrote: >> >> https://cdrdv2.intel.com/v1/dl/getContent/630744?explicitVersion=true >> >> Jeevan Bhungal > > Great! Yeah, the internal link does not work, but the direct link > does. Thank you, Jeevan. The direct link works but does not seem to contain any license information, just a PDF that says "No license (express or implied, by estoppel or otherwise) to any intellectual property rights is granted by this document." I'd like to include these in the Debian non-free package intel-acm. This package currently holds ACM modules published at https://www.intel.com/content/www/us/en/developer/articles/tool/intel-trusted-execution-technology.html under the following license: """ Copyright (c) 2007 - 2011, Intel(R) Corporation. All rights reserved. Redistribution Redistribution and use in binary form, without modification, are permitted provided that the following conditions are met: Redistributions must reproduce the above copyright notice and the following disclaimer in the documentation and/or other materials provided with the distribution. Neither the name of Intel Corporation nor the names of its suppliers may be used to endorse or promote products derived from this software without specific prior written permission. No reverse engineering, decompilation, or disassembly of this software is permitted. Limited patent license Intel Corporation grants a world-wide, royalty-free, non-exclusive license under patents it now or hereafter owns or controls to make, have made, use, import, offer to sell and sell ("Utilize") this software, but solely to the extent that any such patent is necessary to Utilize the software alone. The patent license shall not apply to any combinations which include this software. No hardware per se is licensed hereunder. DISCLAIMER THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. """ Is Intel licensing these new files also under the same license or has the license changed? -Timo |
|
From: Timo L. <tim...@ik...> - 2022-06-13 10:16:02
|
Hi, On Mon, 25 Apr 2022, Jason Andryuk wrote: >> >> https://cdrdv2.intel.com/v1/dl/getContent/630744?explicitVersion=true >> >> Jeevan Bhungal > > Great! Yeah, the internal link does not work, but the direct link > does. Thank you, Jeevan. The direct link works but does not seem to contain any license information, just a PDF that says "No license (express or implied, by estoppel or otherwise) to any intellectual property rights is granted by this document." I'd like to include these in the Debian non-free package intel-acm. This package currently holds ACM modules published at https://www.intel.com/content/www/us/en/developer/articles/tool/intel-trusted-execution-technology.html under the following license: """ Copyright (c) 2007 - 2011, Intel(R) Corporation. All rights reserved. Redistribution Redistribution and use in binary form, without modification, are permitted provided that the following conditions are met: Redistributions must reproduce the above copyright notice and the following disclaimer in the documentation and/or other materials provided with the distribution. Neither the name of Intel Corporation nor the names of its suppliers may be used to endorse or promote products derived from this software without specific prior written permission. No reverse engineering, decompilation, or disassembly of this software is permitted. Limited patent license Intel Corporation grants a world-wide, royalty-free, non-exclusive license under patents it now or hereafter owns or controls to make, have made, use, import, offer to sell and sell ("Utilize") this software, but solely to the extent that any such patent is necessary to Utilize the software alone. The patent license shall not apply to any combinations which include this software. No hardware per se is licensed hereunder. DISCLAIMER THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. """ Is Intel licensing these new files also under the same license or has the license changed? -Timo |
|
From: Tony C. <tc...@re...> - 2022-06-11 22:51:08
|
CORRECTION
> I'm using a RHEL-8.5 based on 5.14 kernel. CentOS 8.5 is the same thing.
^^^^
That's a 4.18 kernel, NOT a 5.14 kernel.
|
15 messages has been excluded from this view by a project administrator.
