Menu
▾
▴
tboot-devel
|
From: Timo L. <tim...@ik...> - 2020-03-31 21:17:02
|
Hi,
if I have the following ACM modules in /boot
018c4c0bc64cad7c939061e111937849f61af395c9981a03ac4a10083058aa5d
4th_gen_i5_i7_SINIT_75.BIN
0848adfea4c9479b1cd096aeda1d4a3afe309dd45ca43a1e8d8b3cf972c9c14f
6th_7th_gen_i5_i7-SINIT_79.bin
193fc2b763bae1b1eebaf15452b395fd5153043190eb61dd86e246914ee7d80e
6th_gen_i5_i7_SINIT_71.BIN
update-grub generates a configuration file like
echo 'Loading tboot 1.9.7 ...'
multiboot2 /tboot.gz logging=serial,memory
echo 'Loading Linux...
module2 /vmlinuz...
echo 'Loading initial ramdisk ...'
module2 /initrd.img...
echo 'Loading sinit 4th_gen_i5_i7_SINIT_75.BIN ...'
module2 /4th_gen_i5_i7_SINIT_75.BIN
echo 'Loading sinit 6th_7th_gen_i5_i7-SINIT_79.bin ...'
module2 /6th_7th_gen_i5_i7-SINIT_79.bin
echo 'Loading sinit 6th_gen_i5_i7_SINIT_71.BIN ...'
module2 /6th_gen_i5_i7_SINIT_71.BIN
Unfortunately if modules are ordered like this the machine will just
reboot after a while.
The machine boots correctly if I order "6th_gen" to be before
"6th_7th_gen" in the above list.
I'm not quite sure which part should be fixed here:
1) Is this a bug in the file 6th_7th_gen? If yes, should it be somehow
blacklisted and/or documented so that users would avoid it?
2) Is this a bug in tboot's logic that tries to pick a matching module? I
could not see anything wrong in the code.
3) Should we fix this in the shell script that generates the configuration
file so that it orders the files "correctly"?
Here's the cpu information and tboot version
cpu:
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 94
model name : Intel(R) Core(TM) i7-6820HQ CPU @ 2.70GHz
stepping : 3
microcode : 0xcc
cpu MHz : 844.213
cache size : 8192 KB
physical id : 0
siblings : 8
core id : 0
cpu cores : 4
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 22
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall
nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good
nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq
dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid
sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c
rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single pti ssbd
ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase
tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx rdseed adx smap
clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln
pts hwp hwp_notify hwp_act_window hwp_epp md_clear flush_l1d
bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf
mds swapgs taa itlb_multihit
bogomips : 5424.00
clflush size : 64
cache_alignment : 64
address sizes : 39 bits physical, 48 bits virtual
power management:
ii tboot 1.9.7-0ubuntu1 amd64 Trusted Boot (tboot)
best regards,
Timo Lindfors
|
|
From: Lukasz H. <luk...@li...> - 2020-04-02 11:15:24
|
On Tue, 2020-03-31 at 23:27 +0300, Timo Lindfors wrote: > Hi, > > if I have the following ACM modules in /boot > > 018c4c0bc64cad7c939061e111937849f61af395c9981a03ac4a10083058aa5d > 4th_gen_i5_i7_SINIT_75.BIN > 0848adfea4c9479b1cd096aeda1d4a3afe309dd45ca43a1e8d8b3cf972c9c14f > 6th_7th_gen_i5_i7-SINIT_79.bin > 193fc2b763bae1b1eebaf15452b395fd5153043190eb61dd86e246914ee7d80e > 6th_gen_i5_i7_SINIT_71.BIN > > update-grub generates a configuration file like > > echo 'Loading tboot 1.9.7 ...' > multiboot2 /tboot.gz logging=serial,memory > echo 'Loading Linux... > module2 /vmlinuz... > echo 'Loading initial ramdisk ...' > module2 /initrd.img... > echo 'Loading sinit 4th_gen_i5_i7_SINIT_75.BIN ...' > module2 /4th_gen_i5_i7_SINIT_75.BIN > echo 'Loading sinit 6th_7th_gen_i5_i7-SINIT_79.bin ...' > module2 /6th_7th_gen_i5_i7-SINIT_79.bin > echo 'Loading sinit 6th_gen_i5_i7_SINIT_71.BIN ...' > module2 /6th_gen_i5_i7_SINIT_71.BIN > > Unfortunately if modules are ordered like this the machine will just > reboot after a while. > > The machine boots correctly if I order "6th_gen" to be before > "6th_7th_gen" in the above list. > > I'm not quite sure which part should be fixed here: > > 1) Is this a bug in the file 6th_7th_gen? If yes, should it be somehow > blacklisted and/or documented so that users would avoid it? > > 2) Is this a bug in tboot's logic that tries to pick a matching module? I > could not see anything wrong in the code. > > 3) Should we fix this in the shell script that generates the configuration > file so that it orders the files "correctly"? > Hi Timo There is a bug in TBOOT that may results in overlapping loaded SINITs by TBOOT's logs. That problem occurs when you load multiple SINITs in GRUB and in most cases the last one will be corrupted. That's why, when TBOOT executes GETSEC[SENTER] CPU fails on SINIT integrity check and resets platform. The workaround for that issue is to have only one SINIT in grub.cfg, so in your scenario you should remove all SINITs except 6th_gen from /boot and recreate grub.cfg Thanks, Lukasz |
|
From: Timo L. <tim...@ik...> - 2020-04-02 14:25:51
|
Hi, On Thu, 2 Apr 2020, Lukasz Hawrylko wrote: > There is a bug in TBOOT that may results in overlapping loaded SINITs by > TBOOT's logs. That problem occurs when you load multiple SINITs in GRUB > and in most cases the last one will be corrupted. That's why, when TBOOT > executes GETSEC[SENTER] CPU fails on SINIT integrity check and resets > platform. > > The workaround for that issue is to have only one SINIT in grub.cfg, so > in your scenario you should remove all SINITs except 6th_gen from /boot > and recreate grub.cfg Is the bug report perhaps available somewhere? I'd very much like to fix this as it is causing many support issues since for example https://fedoraproject.org/wiki/Tboot suggests "You may download all of the ACM modules into /boot and list them all as modules in your grub.conf. tboot will pick the right module for your platform. " I can't change that wiki page as edits are currently not allowed even if I create an account. -Timo |
|
From: Lukasz H. <luk...@li...> - 2020-04-07 09:44:46
|
On Thu, 2020-04-02 at 17:25 +0300, Timo Lindfors wrote: > Hi, > > On Thu, 2 Apr 2020, Lukasz Hawrylko wrote: > > There is a bug in TBOOT that may results in overlapping loaded SINITs by > > TBOOT's logs. That problem occurs when you load multiple SINITs in GRUB > > and in most cases the last one will be corrupted. That's why, when TBOOT > > executes GETSEC[SENTER] CPU fails on SINIT integrity check and resets > > platform. > > > > The workaround for that issue is to have only one SINIT in grub.cfg, so > > in your scenario you should remove all SINITs except 6th_gen from /boot > > and recreate grub.cfg > > Is the bug report perhaps available somewhere? I'd very much like to fix this as it > is causing many support issues since for example > https://fedoraproject.org/wiki/Tboot > > suggests > > "You may download all of the ACM modules into /boot and list them all as > modules in your grub.conf. tboot will pick the right module for your > platform. " > > I can't change that wiki page as edits are currently not allowed even if I > create an account. > > -Timo > Hi Timo Unfortunately, this bug is not reported anywhere. In real life scenarios I don't see any benefits of loading multiple SINITs. In most cases you have one SINIT that is dedicated to the platform. I am not sure if that issue can be fixed without moving TBOOT log memory pool somewhere else and that change will brake other tools. It will be better to change documentation that only one SINIT can be loaded. I will check who is the owner of TBOOT page in Fedora's wiki. Thanks, Lukasz |
|
From: Timo L. <tim...@ik...> - 2020-04-07 13:58:51
|
On Tue, 7 Apr 2020, Lukasz Hawrylko wrote: > Unfortunately, this bug is not reported anywhere. In real life scenarios > I don't see any benefits of loading multiple SINITs. In most cases you > have one SINIT that is dedicated to the platform. The main benefit is that you can automate installation more easily and you can use the same image on all machines. This allows using even a LiveUSB with tboot. If we can't put this logic to tboot then maybe it should be put to the part that generates the grub configuration file at least? I'm open to any other ideas of course. > better to change documentation that only one SINIT can be loaded. I will > check who is the owner of TBOOT page in Fedora's wiki. Thanks! -Timo |
|
From: Timo L. <tim...@ik...> - 2020-04-08 14:13:18
|
On Tue, 7 Apr 2020, Lukasz Hawrylko wrote: > Unfortunately, this bug is not reported anywhere. In real life scenarios > I don't see any benefits of loading multiple SINITs. In most cases you > have one SINIT that is dedicated to the platform. After a closer inspection this might be a different bug as the reboot occurs also if I specify only one SINIT module, the file 6th_gen_i5_i7_SINIT_71.BIN. Why does tboot think that this file is a valid SINIT module for this CPU and try to use it? Is this a bug in the ACM module or tboot? Is there some algorithm for choosing the correct SINIT module? -Timo |
|
From: Lukasz H. <luk...@li...> - 2020-04-08 14:45:35
|
On Wed, 2020-04-08 at 17:12 +0300, Timo Lindfors wrote: > On Tue, 7 Apr 2020, Lukasz Hawrylko wrote: > > Unfortunately, this bug is not reported anywhere. In real life scenarios > > I don't see any benefits of loading multiple SINITs. In most cases you > > have one SINIT that is dedicated to the platform. > > After a closer inspection this might be a different bug as the reboot > occurs also if I specify only one SINIT module, the file > 6th_gen_i5_i7_SINIT_71.BIN. > > Why does tboot think that this file is a valid SINIT module for this CPU > and try to use it? Is this a bug in the ACM module or tboot? Is there some > algorithm for choosing the correct SINIT module? > TBOOT has an algorithm that checks if SINIT matches platform. I can't tell you right now what is wrong here, I need some logs. Please run it once again, than after reboot, can you launch Linux without TBOOT and run 'txt-stat' tool that is in TBOOT's repo in 'utils' folder? What I need is a value of ERRORCODE field. If you can connect serial port and dump serial logs too that will be awesome. Dell's docking station has RS232 connector and TBOOT's logs are printed there (tested on my laptop). Thanks, Lukasz |
|
From: Timo L. <tim...@ik...> - 2020-04-08 19:55:27
|
On Wed, 8 Apr 2020, Lukasz Hawrylko wrote: > If you can connect serial port and dump serial logs too that will be > awesome. Dell's docking station has RS232 connector and TBOOT's logs are > printed there (tested on my laptop). A boot log captured from the monitor using a camera is now available at https://lindi.iki.fi/lindi/tboot/6th_gen_i5_i7_SINIT_71.BIN.tboot.log.png -Timo |
|
From: Timo L. <tim...@ik...> - 2020-04-08 15:58:17
|
On Wed, 8 Apr 2020, Lukasz Hawrylko wrote: > TBOOT has an algorithm that checks if SINIT matches platform. I can't > tell you right now what is wrong here, I need some logs. Please run it > once again, than after reboot, can you launch Linux without TBOOT and > run 'txt-stat' tool that is in TBOOT's repo in 'utils' folder? What I > need is a value of ERRORCODE field. > > If you can connect serial port and dump serial logs too that will be > awesome. Dell's docking station has RS232 connector and TBOOT's logs are > printed there (tested on my laptop). $ txt-stat Intel(r) TXT Configuration Registers: STS: 0x00000012 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: 0x0000000000000008 secrets: FALSE ERRORCODE: 0xc0003c11 DIDVID: 0x00000001b0068086 vendor_id: 0x8086 device_id: 0xb006 revision_id: 0x1 FSBIF: 0xffffffffffffffff QPIIF: 0x000000009d003000 SINIT.BASE: 0xaced0000 SINIT.SIZE: 327680B (0x50000) HEAP.BASE: 0xacf20000 HEAP.SIZE: 917504B (0xe0000) DPR: 0x00000000ad000041 lock: TRUE top: 0xad000000 size: 4MB (4194304B) PUBLIC.KEY: 2d [REDACTED] 77 [REDACTED] *********************************************************** TXT measured launch: FALSE secrets flag set: FALSE *********************************************************** unable to find TBOOT log I'll check if we can get serial output. -Timo |
|
From: Lukasz H. <luk...@li...> - 2020-04-14 07:12:54
|
On Wed, 2020-04-08 at 18:34 +0300, Timo Lindfors wrote: > On Wed, 8 Apr 2020, Lukasz Hawrylko wrote: > > TBOOT has an algorithm that checks if SINIT matches platform. I can't > > tell you right now what is wrong here, I need some logs. Please run it > > once again, than after reboot, can you launch Linux without TBOOT and > > run 'txt-stat' tool that is in TBOOT's repo in 'utils' folder? What I > > need is a value of ERRORCODE field. > > > > If you can connect serial port and dump serial logs too that will be > > awesome. Dell's docking station has RS232 connector and TBOOT's logs are > > printed there (tested on my laptop). > > $ txt-stat > Intel(r) TXT Configuration Registers: > STS: 0x00000012 > 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: 0x0000000000000008 > secrets: FALSE > ERRORCODE: 0xc0003c11 > DIDVID: 0x00000001b0068086 > vendor_id: 0x8086 > device_id: 0xb006 > revision_id: 0x1 > FSBIF: 0xffffffffffffffff > QPIIF: 0x000000009d003000 > SINIT.BASE: 0xaced0000 > SINIT.SIZE: 327680B (0x50000) > HEAP.BASE: 0xacf20000 > HEAP.SIZE: 917504B (0xe0000) > DPR: 0x00000000ad000041 > lock: TRUE > top: 0xad000000 > size: 4MB (4194304B) > PUBLIC.KEY: > 2d [REDACTED] > 77 [REDACTED] > *********************************************************** > TXT measured launch: FALSE > secrets flag set: FALSE > *********************************************************** > unable to find TBOOT log > I had a discussion with people responsible for SINITs for that platform and here is how the situation looks like: * 6th_gen_i5_i7_SINIT_71 is a SkyLake SINIT that was released together with SKL platforms * 6th_7th_gen_i5_i7-SINIT_74 is a KabyLake SINIT that is newer and is backward compatible with SKL platforms As KBL SINIT works with both SKL and KBL platforms, the old one, compatible only with SKL, is not longer supported and may not work with newer versions of SKL bioses. Recommendation is to use the KBL SINIT for both KBL and SKL systems. To avoid possible confusion in the future, old, not longer supported SINIT, will be removed from download site. After that, there will be only one binary available - 6th_7th_gen_i5_i7-SINIT_74 (that works with both SKL and KBL platforms). Please do not use 6th_gen_i5_i7_SINIT_71. Thank you for finding that issue. Lukasz |
|
From: Timo L. <tim...@ik...> - 2020-04-14 07:57:12
|
On Tue, 14 Apr 2020, Lukasz Hawrylko wrote: > As KBL SINIT works with both SKL and KBL platforms, the old one, > compatible only with SKL, is not longer supported and may not work with > newer versions of SKL bioses. Recommendation is to use the KBL SINIT for > both KBL and SKL systems. > > To avoid possible confusion in the future, old, not longer supported > SINIT, will be removed from download site. After that, there will be > only one binary available - 6th_7th_gen_i5_i7-SINIT_74 (that works with > both SKL and KBL platforms). Please do not use 6th_gen_i5_i7_SINIT_71. Great to hear that you found the root cause! Would it be possible to publish a simple tool that can pick the right ACM module for a given CPU automatically? So that I could use that tool to generate my grub.cfg this would greatly improve usability of the whole solution. I can of course try to extract that logic from tboot but maybe such a tool already exists? -Timo |
|
From: Lukasz H. <luk...@li...> - 2020-04-14 08:24:44
|
On Tue, 2020-04-14 at 10:40 +0300, Timo Lindfors wrote: > On Tue, 14 Apr 2020, Lukasz Hawrylko wrote: > > As KBL SINIT works with both SKL and KBL platforms, the old one, > > compatible only with SKL, is not longer supported and may not work with > > newer versions of SKL bioses. Recommendation is to use the KBL SINIT for > > both KBL and SKL systems. > > > > To avoid possible confusion in the future, old, not longer supported > > SINIT, will be removed from download site. After that, there will be > > only one binary available - 6th_7th_gen_i5_i7-SINIT_74 (that works with > > both SKL and KBL platforms). Please do not use 6th_gen_i5_i7_SINIT_71. > Great to hear that you found the root cause! Would it be possible to > publish a simple tool that can pick the right ACM module for a given CPU > automatically? So that I could use that tool to generate my grub.cfg this > would greatly improve usability of the whole solution. I can of course try > to extract that logic from tboot but maybe such a tool already exists? > I don't know if that tool exists. Anyway, I will look at that multiple SINITs bug in TBOOT, when it will be fixed, that kind of tool will not be required. In mean time, you can check acminfo from utils directory. It examines SINIT binary and also can check if SINIT is compatible with current platform. You can easily adopt it (with bash scripting help) to do what you need. Lukasz |
|
From: Timo L. <tim...@ik...> - 2020-04-14 15:51:09
|
On Tue, 14 Apr 2020, Lukasz Hawrylko wrote:
> I don't know if that tool exists. Anyway, I will look at that multiple
> SINITs bug in TBOOT, when it will be fixed, that kind of tool will not
> be required.
True, that would mostly not be needed if tboot worked automatically. I can
think of two use cases where it might still be useful:
1) You could save disk space and boot speed by not having grub read all
SINIT modules from disk.
2) You might want to know before reboot that you have the matching SINIT
module if you are enabling TPM support remotely for your server :)
> In mean time, you can check acminfo from utils directory. It examines
> SINIT binary and also can check if SINIT is compatible with current
> platform. You can easily adopt it (with bash scripting help) to do what
> you need.
Thanks, I will look into that.
Currently I am trying to automate sealing of disk encryption keys
after an upgrade. Here's a quick and dirty prototype that "works on my
server"(TM) but probably contains many bugs. In particular it does not
currently know how to predict PCR-17 and just assumes that it has the same
value on next reboot. Posting it here in the hope that this will activate
discussion on the list for potential alternatives :)
#!/usr/bin/python3
# tpm-luks-auto-seal 2020-04-14
import argparse
import subprocess
import hashlib
import binascii
import glob
import re
import os
import tempfile
INITIAL_HASH = b'\x00'*20
def text_to_hash(text):
hash = binascii.unhexlify(text.replace(' ', '').replace('\n', ''))
assert len(hash) == 20
return hash
def hash_to_text(hash):
assert len(hash) == 20
return binascii.hexlify(hash).decode('utf-8')
def extend_hash(hash1, hash2):
assert len(hash1) == 20
assert len(hash2) == 20
return sha1(hash1 + hash2)
def sha1(data):
m = hashlib.sha1()
m.update(data)
return m.digest()
def predict_pcrs(configuration):
pcr = {}
pcr[17] = get_current_pcrs()[17]
pcr[18] = INITIAL_HASH
tboot_hash = text_to_hash(subprocess.check_output([
'/usr/sbin/lcp_mlehash',
'-c',
configuration.tboot_cmdline,
configuration.tboot], encoding='utf-8'))
pcr[18] = extend_hash(pcr[18], tboot_hash)
with open(configuration.kernel, 'rb') as f:
kernel_hash = sha1(sha1(configuration.kernel_cmdline.encode('utf-8')) + sha1(f.read()))
pcr[18] = extend_hash(pcr[18], kernel_hash)
pcr[19] = INITIAL_HASH
with open(configuration.initrd, 'rb') as f:
initrd_hash = sha1(sha1(b'') + sha1(f.read()))
pcr[19] = extend_hash(pcr[19], initrd_hash)
return pcr
class Configuration:
def __init__(self, tboot, tboot_cmdline, kernel, kernel_cmdline, initrd):
self.tboot = tboot
self.tboot_cmdline = tboot_cmdline
self.kernel = kernel
self.kernel_cmdline = kernel_cmdline
self.initrd = initrd
def __str__(self):
return "{}({}) {}({}) {}".format(self.tboot, self.tboot_cmdline, self.kernel, self.kernel_cmdline, self.initrd)
def get_current_pcrs():
pcrs = {}
with open("/sys/devices/pnp0/00:05/tpm/tpm0/pcrs") as f:
for line in f.readlines():
assert line.startswith("PCR-")
n = int(line.split(":")[0].split("-")[1])
pcrs[n] = text_to_hash(line.split(":")[1])
return pcrs
def get_grub_entries(cfg, prefix):
inside_entry = False
entries = []
with open(cfg) as f:
for line in f.readlines():
line = line.rstrip().strip()
if line.startswith("menuentry"):
inside_entry = True
entry = {}
elif inside_entry:
parts = re.split("\s+", line)
if line.startswith("}"):
if "tboot_cmdline" in entry:
entries.append(entry)
inside_entry = False
elif parts[0] == "multiboot":
entry["tboot"] = prefix + parts[1]
entry["tboot_cmdline"] = parts[2]
elif parts[0] == "module" and "vmlinuz" in parts[1]:
entry["kernel"] = prefix + parts[1]
entry["kernel_cmdline"] = " ".join(parts[2:])
elif parts[0] == "module" and "initrd" in parts[1]:
entry["initrd"] = prefix + parts[1]
return entries
def get_configurations():
configurations = []
for e in get_grub_entries("/boot/grub/grub.cfg", "/boot"):
assert os.path.exists(e["tboot"])
assert os.path.exists(e["kernel"])
assert os.path.exists(e["initrd"])
if " single " in e["kernel_cmdline"]:
# Skip for now
continue
c = Configuration(tboot=e["tboot"],
tboot_cmdline=e["tboot_cmdline"],
kernel=e["kernel"],
kernel_cmdline=e["kernel_cmdline"],
initrd=e["initrd"])
configurations.append(c)
return configurations
if __name__ == "__main__":
parser = argparse.ArgumentParser()
parser.add_argument("--luks-key-file", default="/etc/luks.key")
parser.add_argument("--force", action="store_true")
args = parser.parse_args()
print("==== Current configuration")
current_pcr = get_current_pcrs()
for i in range(17, 20):
print("PCR-{} {}".format(i, hash_to_text(current_pcr[i])))
configurations = get_configurations()
count = 1
pcrs = []
for c in configurations:
print("==== Predicted configuration #{}".format(count))
print("# {}".format(c))
pcr = predict_pcrs(c)
for i in range(17, 20):
print("PCR-{} {}{}".format(i, hash_to_text(pcr[i]), "*" if pcr[i]!=current_pcr[i] else ""))
count += 1
pcrs.append(pcr)
with open(args.luks_key_file) as f:
luks_key_length = len(f.read())
assert luks_key_length >= 12
assert luks_key_length < 128
if not args.force:
reply = input("Do you want to enable these configurations (use --force to automate this) (Y/n)? ")
if not reply.lower().startswith("y"):
print("Aborting")
sys.exit(0)
print("Removing old configurations (1-20)")
for i in range(20):
try:
subprocess.check_call(["tpm_nvrelease",
"-i", str(i+1),
"--pwdo=1234"])
except subprocess.CalledProcessError:
pass
for i in range(len(configurations)):
print("Enabling configuration #{}".format(i+1))
with tempfile.NamedTemporaryFile(mode="w+") as f:
for j in range(17, 20):
f.write("r {} {}\n".format(j, hash_to_text(pcrs[i][j])))
f.flush()
subprocess.check_call(["tpm_nvdefine",
"-i", str(i+1),
"-s", str(luks_key_length),
"-p", "OWNERWRITE|READ_STCLEAR",
"--pwdo=1234",
"-z",
"-f", f.name])
subprocess.check_call(["tpm_nvwrite",
"-i", str(i+1),
"-f", args.luks_key_file,
"-z", "--password=1234"])
-Timo
|
|
From: Timo L. <tim...@ik...> - 2021-08-24 11:22:13
|
[replying to an old email thread] On Tue, 7 Apr 2020, Lukasz Hawrylko wrote: > Unfortunately, this bug is not reported anywhere. In real life scenarios > I don't see any benefits of loading multiple SINITs. In most cases you > have one SINIT that is dedicated to the platform. > > I am not sure if that issue can be fixed without moving TBOOT log memory > pool somewhere else and that change will brake other tools. It will be > better to change documentation that only one SINIT can be loaded. I will > check who is the owner of TBOOT page in Fedora's wiki. Just for the record I hit this issue again on HP Elitedesk 800 G2 in UEFI-only mode. Loading 2nd_gen_i5_i7_SINIT_51.BIN 3rd_gen_i5_i7_SINIT_67.BIN 4th_gen_i5_i7_SINIT_75.BIN 5th_gen_i5_i7_SINIT_79.BIN 6th_7th_gen_i5_i7-SINIT_79.bin 7th_8th_gen_i5_i7-SINIT_81.bin GM45_GS45_PM45_SINIT_51.BIN Q35_SINIT_51.BIN Q45_Q43_SINIT_51.BIN Xeon-5600-3500-SINIT-v1.1.bin Xeon-E7-8800-4800-2800-SINIT-v1.1.bin i5_i7_DUAL_SINIT_51.BIN i7_QUAD_SINIT_51.BIN causes the system to reset at SENTER with TBOOT: TXT.ERRORCODE: 0x80000007 TBOOT: processor error 0x7 Loading only sinit 6th_7th_gen_i5_i7-SINIT_79.bin works: TBOOT: checking if module is an SINIT for this platform... TBOOT: chipset production fused: 1 TBOOT: chipset ids: vendor: 0x8086, device: 0xb006, revision: 0x1 TBOOT: processor family/model/stepping: 0x506e3 TBOOT: platform id: 0x4000000000000 TBOOT: 1 ACM chipset id entries: TBOOT: vendor: 0x8086, device: 0xb006, flags: 0x1, revision: 0x1, extended: 0x0 TBOOT: 4 ACM processor id entries: TBOOT: fms: 0x406e0, fms_mask: 0xfff3ff0, platform_id: 0x0, platform_mask: 0x0 TBOOT: fms: 0x506e0, fms_mask: 0xfff3ff0, platform_id: 0x0, platform_mask: 0x0 TBOOT: SINIT matches platform ... TBOOT: SINIT ACM successfully returned... Could you try to contact again Fedora to get the wiki page fixed? It is still misleading people into putting all ACMs to /boot. I could not figure out how to modify the wiki as it seems to be very restricted due to spam challenges. Should we fix ./tboot/20_linux_tboot to complain if multiple ACMs are present? I would really prefer an error message over a system reset that is difficult to diagnose without serial console. Or should 20_linux_tboot try to automatically select the correct ACM? Or perhaps even create one boot entry per ACM to some submenu? -Timo |
|
From: Lukasz H. <luk...@li...> - 2021-08-24 11:58:51
|
Hi Timo On Tue, 2021-08-24 at 12:19 +0300, Timo Lindfors wrote: > [replying to an old email thread] > > On Tue, 7 Apr 2020, Lukasz Hawrylko wrote: > > Unfortunately, this bug is not reported anywhere. In real life scenarios > > I don't see any benefits of loading multiple SINITs. In most cases you > > have one SINIT that is dedicated to the platform. > > > > I am not sure if that issue can be fixed without moving TBOOT log memory > > pool somewhere else and that change will brake other tools. It will be > > better to change documentation that only one SINIT can be loaded. I will > > check who is the owner of TBOOT page in Fedora's wiki. > > Just for the record I hit this issue again on HP Elitedesk 800 G2 in > UEFI-only mode. Loading > > 2nd_gen_i5_i7_SINIT_51.BIN > 3rd_gen_i5_i7_SINIT_67.BIN > 4th_gen_i5_i7_SINIT_75.BIN > 5th_gen_i5_i7_SINIT_79.BIN > 6th_7th_gen_i5_i7-SINIT_79.bin > 7th_8th_gen_i5_i7-SINIT_81.bin > GM45_GS45_PM45_SINIT_51.BIN > Q35_SINIT_51.BIN > Q45_Q43_SINIT_51.BIN > Xeon-5600-3500-SINIT-v1.1.bin > Xeon-E7-8800-4800-2800-SINIT-v1.1.bin > i5_i7_DUAL_SINIT_51.BIN > i7_QUAD_SINIT_51.BIN > > causes the system to reset at SENTER with > > TBOOT: TXT.ERRORCODE: 0x80000007 > TBOOT: processor error 0x7 > Patch with fix is already prepared, I am waiting for GRUB team to merge new multiboot2 module tag to publish it. In meantime, if you have a system when you are able to reproduce this issue, may I ask you to test the fix? You have to build GRUB2 with following patch: https://lists.gnu.org/archive/html/grub-devel/2021-08/msg00073.html Here is a patch for TBOOT that uses changes in GRUB: diff -r 6736ab640540 -r 47180cb4492f tboot/common/boot.S --- a/tboot/common/boot.S Tue Jul 06 11:02:08 2021 +0200 +++ b/tboot/common/boot.S Thu Aug 19 14:17:40 2021 +0200 @@ -113,6 +113,13 @@ FB_MAX_VRES, /* height */ \ FB_BPP /* depth */ + /* Module load preference tag */ + mb2ht_init MB2_HDR_TAG_MOD_LOAD_PREFERENCE, MB2_HDR_TAG_OPTIONAL, \ + 0x900000, /* min_addr */ \ + 0xFFFFFFFF, /* max_addr */ \ + 0x1000, /* align */ \ + 0 /* preference */ + /* Multiboot2 header end tag. */ mb2ht_init MB2_HDR_TAG_END, MB2_HDR_TAG_REQUIRED diff -r 6736ab640540 -r 47180cb4492f tboot/include/multiboot.h --- a/tboot/include/multiboot.h Tue Jul 06 11:02:08 2021 +0200 +++ b/tboot/include/multiboot.h Thu Aug 19 14:17:40 2021 +0200 @@ -77,6 +77,7 @@ #define MB2_HDR_TAG_CONSOLE_FLAGS 4 #define MB2_HDR_TAG_FRAMEBUFFER 5 #define MB2_HDR_TAG_MOD_ALIGN 6 +#define MB2_HDR_TAG_MOD_LOAD_PREFERENCE 11 #define MB2_HDR_TAG_REQUIRED 0 #define MB2_HDR_TAG_OPTIONAL 1 If this works, I think that there is no need to change anything in the documentation, but just submit the patch to fix that issue. Thanks, Lukasz |
|
From: Timo L. <tim...@ik...> - 2021-08-25 08:31:26
|
On Tue, 24 Aug 2021, Lukasz Hawrylko wrote: > Patch with fix is already prepared, I am waiting for GRUB team to merge > new multiboot2 module tag to publish it. > > In meantime, if you have a system when you are able to reproduce this > issue, may I ask you to test the fix? Sure. I applied these to the Debian packages grub2 2.04-20 tboot 1.10.2+dfsg.0-1 and can now boot the system with multiple ACM modules in /boot. Is there something else I should test as well? -Timo |
|
From: Lukasz H. <luk...@li...> - 2021-08-26 09:10:46
|
On Wed, 2021-08-25 at 09:28 +0300, Timo Lindfors wrote: > On Tue, 24 Aug 2021, Lukasz Hawrylko wrote: > > Patch with fix is already prepared, I am waiting for GRUB team to merge > > new multiboot2 module tag to publish it. > > > > In meantime, if you have a system when you are able to reproduce this > > issue, may I ask you to test the fix? > > Sure. I applied these to the Debian packages > > grub2 2.04-20 > tboot 1.10.2+dfsg.0-1 > > and can now boot the system with multiple ACM modules in /boot. Is there > something else I should test as well? You can check if txt-stat dumps TBOOT log correctly. Nothing else comes into my mind. Lukasz |
|
From: Timo L. <tim...@ik...> - 2021-08-26 10:08:06
Attachments:
txt-stat.output.gz
|
On Thu, 26 Aug 2021, Lukasz Hawrylko wrote: > You can check if txt-stat dumps TBOOT log correctly. Nothing else comes > into my mind. Looks normal to me. I've attached a compressed version to this mail. -Timo |
|
From: Lukasz H. <luk...@li...> - 2021-08-26 11:51:09
|
On Thu, 2021-08-26 at 11:05 +0300, Timo Lindfors wrote: > On Thu, 26 Aug 2021, Lukasz Hawrylko wrote: > > You can check if txt-stat dumps TBOOT log correctly. Nothing else comes > > into my mind. > > Looks normal to me. I've attached a compressed version to this mail. Looks good, thank you for your tests. As soon as GRUB maintainers accept the patch, I will push changes to TBOOT upstream. Lukasz |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X