Save EFI BootX variables when (un)sealing storage key #4612
Conversation
rucoder
force-pushed
the
rucoder/monitor-tpm-log
branch
from
2318db4 to
72baaeb
Compare
rucoder
force-pushed
the
rucoder/monitor-tpm-log
branch
2 times, most recently
from
8f3ed02 to
6d0478e
Compare
There was a problem hiding this comment.
I see that we only copy BootOrder and BootXXXX variables, but not any other EFI variables (e.g., keys like PK-, db-, dbx-, etc.). In some scenarios, these other EFI variables may be measured into PCRs as well (particularly on platforms with certain secure-boot flows), so it might be worth considering whether we want to save those, too. If someone’s unsealing fails because of changes in another EFI variable that we currently don’t copy, the debugging data will still be incomplete. Could that be an issue for certain platforms?
Also, I notice that we do not yet provide an automated way to compare the “fail” vs. “success” snapshots. This is presumably meant for a manual, ad-hoc diff to investigate unseal failures. It would be helpful to document this workflow so that others know.
Something like...
If unsealing fails, check the snapshot in /persist/status/boot_vars/fail,
Compare against /persist/status/boot_vars/success,
Check the relevant measurement logs in /persist/status/tpm_measurement_{unseal_fail,seal_success},
Identify which bytes changed.
Nevertheless, for this particular case, it may be enough, so approving.
|
LGTM. |
@OhmSpectator other variables are more like "yes/no" flags for analysis. For example "SecureBoot" -- we only care whether this variable is present or not and do not care about attached data. And the data attached to event log is good enough for human analysis but I need to extract data automatically and unfortunately the format is not well defined in specs and manufactures do what they want.
TUI does that |
Ah, got it! Maybe add it as a comment: the produced files are later consumed by another component. |
isn't it enough :) ? |
Enough indeed. Sorry, missed it. |
pkg/pillar/evetpm/tpm.go
Outdated
| bootVarRegex := regexp.MustCompile(fmt.Sprintf(`^Boot[0-9a-fA-F]{4}-%s$`, efiGlobalVariableGUID)) | ||
|
|
||
| for _, file := range files { | ||
| if bootOrderRegex.MatchString(file.Name()) || bootVarRegex.MatchString(file.Name()) { |
There was a problem hiding this comment.
| if bootOrderRegex.MatchString(file.Name()) || bootVarRegex.MatchString(file.Name()) { | |
| if file.Name() == fmt.Sprintf(`BootOrder-%s`, efiGlobalVariableGUID) || bootVarRegex.MatchString(file.Name()) { |
|
Tests? |
To do a proper analysis a monitor TUI we need values of BootXXXX and
BootOrder EFI variables. Variable data for them is present in the TPM
log however neither TCG spec nor UEFI spec mandate what part of
EFI_LOAD_OPTION structure is serialized and measured in the TPM log so
the reliable extraction is not possible. For example UEFI on NUC13
device avoids first two fields of this structure.
- save variables to /persist/status/boot_vars/{success,fail} directories
Export paths by introducing GetBootVariablesDirNames()
- export paths to saved TPM logs by introducing GetTpmLogFileNames()
and GetTpmLogBackupFileNames()
Signed-off-by: Mikhail Malyshev <[email protected]>
rucoder
force-pushed
the
rucoder/monitor-tpm-log
branch
from
6d0478e to
81db9bf
Compare
I think we have users which use the meta-data server to retrieve the output from diag and then present that using their app instance screen. Is there a way we can make this comparison common so that both the TUI and diag can present it and as a result it will also appear in the meta-data server output? |
@eriknordmark I'll think of it but not in this iteration. I already have libs for parsing logs and EFI structures and re-implementing it would take too much time. Porting it back to EVE will take much less time when it is ready and tested |
To do a proper analysis in a monitor TUI we need values of BootXXXX and BootOrder EFI variables. Variable data for them is present in the TPM log however neither TCG spec nor UEFI spec mandate what part of EFI_LOAD_OPTION structure is serialized and measured in the TPM log so the reliable extraction is not possible. For example UEFI on NUC13 device avoids first two fields of this structure.