chore(test): Update fingerprint baselines #3813

zulinx86 · 2023-06-12T10:27:17Z

Note that the root cause analysis for guest CPU config change on Cascade Lake is being done in parallel. This PR goes first to unblock CI failures on the other PRs.

Changes

Regathers the fingerprint baseline files.

Reason

Some kernel versions, microcode versions and guest CPU configs are updated.

License Acceptance

By submitting this pull request, I confirm that my contribution is made under
the terms of the Apache 2.0 license. For more information on following
Developer Certificate of Origin and signing off your commits, please check
CONTRIBUTING.md.

PR Checklist

~~[ ] If a specific issue led to this PR, this PR closes the issue.~~
The description of changes is clear and encompassing.
~~[ ] Any required documentation changes (code and docs) are included in this PR.~~
~~[ ] API changes follow the Runbook for Firecracker API changes.~~
~~[ ] User-facing changes are mentioned in CHANGELOG.md.~~
All added/changed functionality is tested.
~~[ ] New TODOs link to an issue.~~
Commits meet contribution quality standards.

This functionality cannot be added in rust-vmm.

The host information (kernel version and CPU info) always has to be displayed even when the test is aborted unexpectedly in the middle. Signed-off-by: Takahiro Itazuri <itazur@amazon.com>

Adds a missing dash "-" to the fingerprint comparison command of the CPU template helper tool. Signed-off-by: Takahiro Itazuri <itazur@amazon.com>

Regathers the fingerprint baseline files where some kernel versions, microcode versions and guest CPU configs are updated. Signed-off-by: Takahiro Itazuri <itazur@amazon.com>

tools/devtool

tests/integration_tests/functional/test_cpu_template_helper.py

resources/tests/cpu_template_helper/fingerprint_AMD_MILAN_4.14host.json

We updated the fingerprint files in PR firecracker-microvm#3813, since Intel microcode release (microcode-20230512) changed to set IA32_ARCH_CAPABILITIES.RRSBA (bit 19) to 1 on Intel CascadeLake CPU. The mitigation itself is already in place which is eIBRS. Since the kernel enables eIBRS by default using SPECTRE_V2_EIBRS mode regardless of the IA32_ARCH_CAPABILITIES.RRSBA bit, hosts and guests should not get impacted by this change. However, it has a role to inform softwares whether the part has the RRSBA behavior. The T2S template has set it to 0 explicitly before, but this commit changes to set it to 1 so that guest kernels and applications can know that the processor has the RRSBA behavior. The reason why it sets the bit to 1 instead of passing through it from the host is that it aims to provide the ability to securely migrate snapshots between Intel Skylake and Intel CascadeLake. Signed-off-by: Takahiro Itazuri <itazur@amazon.com>

We updated the fingerprint files in PR firecracker-microvm#3813, since Intel microcode release (microcode-20230512) changed to set IA32_ARCH_CAPABILITIES.RRSBA (bit 19) to 1 on Intel CascadeLake CPU. The mitigation itself is already in place which is eIBRS. Since the kernel enables eIBRS by default using SPECTRE_V2_EIBRS mode regardless of the IA32_ARCH_CAPABILITIES.RRSBA bit, hosts and guests should not get impacted by this change. However, it has a role to inform softwares whether the part has the RRSBA behavior. The T2CL template has set it to 0 explicitly before, but this commit changes to pass through the bit from the host so that guest kernels and applications can know that the processor has the RRSBA behavior. The reason why it passes through the bit from the host opposed to the T2S template is that the T2CL template is not designed to allow snapshot migration between different CPU models. Signed-off-by: Takahiro Itazuri <itazur@amazon.com>

We updated the fingerprint files in PR firecracker-microvm#3813, since Intel microcode release (microcode-20230512) changed to set IA32_ARCH_CAPABILITIES.RRSBA (bit 19) to 1 on Intel CascadeLake CPU. The mitigation itself is already in place which is eIBRS. Since the kernel enables eIBRS by default using SPECTRE_V2_EIBRS mode regardless of the IA32_ARCH_CAPABILITIES.RRSBA bit, hosts and guests should not get impacted by this change. However, it has a role to inform softwares whether the part has the RRSBA behavior. The T2S template has set it to 0 explicitly before, but this commit changes to set it to 1 so that guest kernels and applications can know that the processor has the RRSBA behavior. The reason why it sets the bit to 1 instead of passing through it from the host is that it aims to provide the ability to securely migrate snapshots between Intel Skylake and Intel CascadeLake. Signed-off-by: Takahiro Itazuri <itazur@amazon.com>

We updated the fingerprint files in PR firecracker-microvm#3813, since Intel microcode release (microcode-20230512) changed to set IA32_ARCH_CAPABILITIES.RRSBA (bit 19) to 1 on Intel CascadeLake CPU. The mitigation itself is already in place which is eIBRS. Since the kernel enables eIBRS by default using SPECTRE_V2_EIBRS mode regardless of the IA32_ARCH_CAPABILITIES.RRSBA bit, hosts and guests should not get impacted by this change. However, it has a role to inform softwares whether the part has the RRSBA behavior. The T2CL template has set it to 0 explicitly before, but this commit changes to pass through the bit from the host so that guest kernels and applications can know that the processor has the RRSBA behavior. The reason why it passes through the bit from the host opposed to the T2S template is that the T2CL template is not designed to allow snapshot migration between different CPU models. Signed-off-by: Takahiro Itazuri <itazur@amazon.com>

We updated the fingerprint files in PR firecracker-microvm#3813, since Intel microcode release (microcode-20230512) changed to set IA32_ARCH_CAPABILITIES.RRSBA (bit 19) to 1 on Intel CascadeLake CPU. The mitigation itself is already in place which is eIBRS. Since the kernel enables eIBRS by default using SPECTRE_V2_EIBRS mode regardless of the IA32_ARCH_CAPABILITIES.RRSBA bit, hosts and guests should not get impacted by this change. However, it has a role to inform softwares whether the part has the RRSBA behavior. The T2CL template has set the RRSBA bit to 0 explicitly before, but this commit changes to pass through the bit from the host so that guest kernels and applications can know that the processor has the RRSBA behavior. The reason why it passes through the bit from the host opposed to the T2S template is that the T2CL template is not designed to allow snapshot migration between different CPU models. In addition to the RRSBA bit, this comit also changes to pass through the RSBA bit, as it is safer to let guest know these informative bits of the host CPU than to overwrite them with templates. Signed-off-by: Takahiro Itazuri <itazur@amazon.com>

We updated the fingerprint files in PR firecracker-microvm#3813, since Intel microcode release (microcode-20230512) changed to set IA32_ARCH_CAPABILITIES.RRSBA (bit 19) to 1 on Intel CascadeLake CPU. The mitigation itself is already in place which is eIBRS. Since the kernel enables eIBRS by default using SPECTRE_V2_EIBRS mode regardless of the IA32_ARCH_CAPABILITIES.RRSBA bit, hosts and guests should not get impacted by this change. However, it has a role to inform softwares whether the part has the RRSBA behavior. The T2S template has set it to 0 explicitly before, but this commit changes to set it to 1 so that guest kernels and applications can know that the processor has the RRSBA behavior. The reason why it sets the bit to 1 instead of passing through it from the host is that it aims to provide the ability to securely migrate snapshots between Intel Skylake and Intel CascadeLake. Signed-off-by: Takahiro Itazuri <itazur@amazon.com>

We updated the fingerprint files in PR firecracker-microvm#3813, since Intel microcode release (microcode-20230512) changed to set IA32_ARCH_CAPABILITIES.RRSBA (bit 19) to 1 on Intel CascadeLake CPU. The mitigation itself is already in place which is eIBRS. Since the kernel enables eIBRS by default using SPECTRE_V2_EIBRS mode regardless of the IA32_ARCH_CAPABILITIES.RRSBA bit, hosts and guests should not get impacted by this change. However, it has a role to inform softwares whether the part has the RRSBA behavior. The T2CL template has set the RRSBA bit to 0 explicitly before, but this commit changes to pass through the bit from the host so that guest kernels and applications can know that the processor has the RRSBA behavior. The reason why it passes through the bit from the host opposed to the T2S template is that the T2CL template is not designed to allow snapshot migration between different CPU models. In addition to the RRSBA bit, this comit also changes to pass through the RSBA bit, as it is safer to let guest know these informative bits of the host CPU than to overwrite them with templates. Signed-off-by: Takahiro Itazuri <itazur@amazon.com>

We updated the fingerprint files in PR firecracker-microvm#3813, since Intel microcode release (microcode-20230512) changed to set IA32_ARCH_CAPABILITIES.RRSBA (bit 19) to 1 on Intel CascadeLake CPU. The mitigation itself is already in place which is eIBRS. Since the kernel enables eIBRS by default using SPECTRE_V2_EIBRS mode regardless of the IA32_ARCH_CAPABILITIES.RRSBA bit, hosts and guests should not get impacted by this change. However, it has a role to inform softwares whether the part has the RRSBA behavior. The T2S template has set it to 0 explicitly before, but this commit changes to set it to 1 so that guest kernels and applications can know that the processor has the RRSBA behavior. The reason why it sets the bit to 1 instead of passing through it from the host is that it aims to provide the ability to securely migrate snapshots between Intel Skylake and Intel CascadeLake. Signed-off-by: Takahiro Itazuri <itazur@amazon.com>

We updated the fingerprint files in PR #3813, since Intel microcode release (microcode-20230512) changed to set IA32_ARCH_CAPABILITIES.RRSBA (bit 19) to 1 on Intel CascadeLake CPU. The mitigation itself is already in place which is eIBRS. Since the kernel enables eIBRS by default using SPECTRE_V2_EIBRS mode regardless of the IA32_ARCH_CAPABILITIES.RRSBA bit, hosts and guests should not get impacted by this change. However, it has a role to inform softwares whether the part has the RRSBA behavior. The T2S template has set it to 0 explicitly before, but this commit changes to set it to 1 so that guest kernels and applications can know that the processor has the RRSBA behavior. The reason why it sets the bit to 1 instead of passing through it from the host is that it aims to provide the ability to securely migrate snapshots between Intel Skylake and Intel CascadeLake. Signed-off-by: Takahiro Itazuri <itazur@amazon.com>

We updated the fingerprint files in PR #3813, since Intel microcode release (microcode-20230512) changed to set IA32_ARCH_CAPABILITIES.RRSBA (bit 19) to 1 on Intel CascadeLake CPU. The mitigation itself is already in place which is eIBRS. Since the kernel enables eIBRS by default using SPECTRE_V2_EIBRS mode regardless of the IA32_ARCH_CAPABILITIES.RRSBA bit, hosts and guests should not get impacted by this change. However, it has a role to inform softwares whether the part has the RRSBA behavior. The T2CL template has set the RRSBA bit to 0 explicitly before, but this commit changes to pass through the bit from the host so that guest kernels and applications can know that the processor has the RRSBA behavior. The reason why it passes through the bit from the host opposed to the T2S template is that the T2CL template is not designed to allow snapshot migration between different CPU models. In addition to the RRSBA bit, this comit also changes to pass through the RSBA bit, as it is safer to let guest know these informative bits of the host CPU than to overwrite them with templates. Signed-off-by: Takahiro Itazuri <itazur@amazon.com>