runtime: make SNP guest policy configurable #11675
Conversation
| @@ -72,6 +72,9 @@ valid_hypervisor_paths = @QEMUSNPVALIDHYPERVISORPATHS@ | |||
| # for the SNP_LAUNCH_FINISH command defined in the SEV-SNP firmware ABI (QEMU default: all-zero) | |||
| #snp_id_auth = "" | |||
|
|
|||
| # SNP Guest Policy, the ‘POLICY’ parameter to the SNP_LAUNCH_START command. | |||
| #snp_guest_policy = 196608 | |||
There was a problem hiding this comment.
This is ... not so user friendly.
Would be possible to have a string set here (a more descriptive one, if possible) and then on the runtime side take care of converting that to the specific number?
That would improve not only readability / maintainability, but also the user experience.
Also, please, add in the comment the possible options available.
There was a problem hiding this comment.
Would be possible to have a string set here (a more descriptive one, if possible) and then on the runtime side take care of converting that to the specific number?
@fidencio I want to be able to set a specific values as soon as the firmware I deploy allows it. If we start to disassemble/reassemble that value, I'm blocked again waiting on Kata update when I need to enable security-critical things in the guest policy.
Also, the snp_id_block/snp_id_auth fields are opaque, too, the way we currently handle them.
This is ... not so user friendly.
These are toggles for experienced SNP users/Kata integrators. They are just a passthru to the qemu command line.
Also, please, add in the comment the possible options available.
That depends on the firmware you've deployed on your Platform as well as the host kernel.
There was a problem hiding this comment.
Hmm. Is this part of any measurement?
I'm fine with the code as it is, your rationale makes sense. I am now trying to understand what happens if someone sets something different ...
There was a problem hiding this comment.
I've added some more context, also updated the description of the id block field.
The policy is part of the attestation report, but foremost, it is enforced at VM launch time, and it is in part also configuration for the CVM. For example, you can set an ABI version in the policy, and your VM won't start if the host isn't running at least that ABI.
Dependening on the platform configuration, users might want to set a more secure policy than the QEMU default. Signed-off-by: Paul Meyer <katexochen0@gmail.com>
a3ce465 to
5635410
Compare
Dependening on the platform configuration, users might want to set a more secure policy than the QEMU default.