efi: implement platform-agnostic arm64 host security checks - #566
efi: implement platform-agnostic arm64 host security checks#566alexclewontin wants to merge 2 commits into
Conversation
| return checkHostSecurityARM64Generic(env, log, integrity) | ||
| } | ||
|
|
||
| func checkHostSecurityARM64Generic(env internal_efi.HostEnvironment, log *tcglog.Log, integrity platformFirmwareIntegrityConfig) (platformFirmwareIntegrityConfig, error) { |
There was a problem hiding this comment.
This does not look very Arm64 specific and duplicates code from checkHostSecurityAMD64.
Could both be merged? (does it make sense?)
Or do you intend to make them diverge in the next PR?
| ))) | ||
| } | ||
|
|
||
| newDevices := func(tpmDriver string, withIOMMU bool) []internal_efi.SysfsDevice { |
There was a problem hiding this comment.
same question as for intelDevices in PR#565: #565 (comment)
| ) | ||
|
|
||
| func init() { | ||
| RegisterARM64TestPlatform(exampleARM64CPUManufacturer, exampleARM64CPUVersion) |
There was a problem hiding this comment.
Please add a comment about what is the purpose of this, and why this is done here.
Wouldn't it be more explicit to have this done in the setup of one of the test suites instead?
| return func() { runtimeGOARCH = orig } | ||
| } | ||
|
|
||
| func RegisterARM64TestPlatform(cpuManufacturer, cpuVersion string) { |
There was a problem hiding this comment.
Please add a description of this function.
|
|
||
| eventLogPath = "/sys/kernel/security/tpm0/binary_bios_measurements" // Path of the TCG event log for the default TPM, in binary form | ||
|
|
||
| dmiProcessorInfoPath = "/sys/firmware/dmi/entries/4-0/raw" |
There was a problem hiding this comment.
Does "4" means type 4?
Does "0" means processor 0? Do we make any assumption there (eg: that other CPUs are the same as CPU 0...)
Please document these.
2 participants
This PR adds a framework for host security checks on arm64 platforms. It moves #564 to the stack.
It adds a generic framework to check host security on ARM64. Very few truly cross-platform APIs were found to be applicable to that ecosystem, but we can use the backing driver for the TPM to prove that a given TPM is a fTPM: if it is using the OP-TEE fTPM driver we can be sure that it is an fTPM. This is not conclusive (absence of that driver doesn't prove that a TPM is a dTPM), but it is a common reference implementation for the ARM ecosystem, so worth including.