Skip to content

kernel/attest: validate AttestServicesOp and AttestSingleServiceOp#711

Open
stefano-garzarella wants to merge 1 commit intococonut-svsm:mainfrom
stefano-garzarella:fix-attest-validation
Open

kernel/attest: validate AttestServicesOp and AttestSingleServiceOp#711
stefano-garzarella wants to merge 1 commit intococonut-svsm:mainfrom
stefano-garzarella:fix-attest-validation

Conversation

@stefano-garzarella
Copy link
Copy Markdown
Member

Commit 0ae2ab7 ("Add attest_multiple_services") used read_from_guest to create an instance of AttestServicesOp or AttestSingleServiceOp, but we didn't validate them like we do in try_from_as_ref().

So let's provide for both a new try_from_guest() method where we can validate them. Probably in the future we should provide a trait (e.g. FromGuest) that each structure can implement in order to standardize our code.

Fixes: 0ae2ab7 ("Add attest_multiple_services")

Commit 0ae2ab7 ("Add attest_multiple_services") used `read_from_guest`
to create an instance of `AttestServicesOp` or `AttestSingleServiceOp`,
but we didn't validate them like we do in `try_from_as_ref()`.

So let's provide for both a new `try_from_guest()` method where we can
validate them. Probably in the future we should provide a trait
(e.g. `FromGuest`) that each structure can implement in order to
standardize our code.

Fixes: 0ae2ab7 ("Add attest_multiple_services")
Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
Comment on lines +63 to +65
if !ops.is_reserved_clear() {
return Err(SvsmReqError::invalid_parameter());
}
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we not also want to check the validity requirements of the nonce and manifest?
We can then say that there's the PreAttestServicesOp type that is structurally all the fields to read, and try_from_guest returns AttestServicesOp which is ensured to have valid fields. That allows all the get_ methods to not need to do any wellformedness checks.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we not also want to check the validity requirements of the nonce and manifest?

Maybe yes, but I just followed what we did in try_from_as_ref() so I guess we should fix both.

We can then say that there's the PreAttestServicesOp type that is structurally all the fields to read, and try_from_guest returns AttestServicesOp which is ensured to have valid fields. That allows all the get_ methods to not need to do any wellformedness checks.

Yep, this is something similar to what I did in #603 where I added a generic validate() method called by the try_from_* API. Maybe I can do the same here (in another commit). WDYT?

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think even moreso here and there. both TpmSendCommandRequest and AttestServicesOp ought to have their fields in TpmSendCommandRequestState/AttestServicesOpState structs that get embedded in TpmSendCommandRequest/AttestServicesOp only if their values pass validation. This ensures that operations are only associated with the struct type that maintains the wellformedness invariant.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we make fields private and provide only try_from* method to build those structures, we should have the same, without embending them, no?
Or maybe I'm missing something.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we make fields private and provide only try_from* method to build those structures, we should have the same, without embending them, no? Or maybe I'm missing something.

@deeglaze WDYT?

@joergroedel joergroedel added the in-review PR is under active review and not yet approved label Jun 10, 2025
@stefano-garzarella stefano-garzarella added the wait-for-update PR is waiting to be updated to address review comments label Feb 12, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

in-review PR is under active review and not yet approved wait-for-update PR is waiting to be updated to address review comments

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants