Adds the attest structures

[Superhepper]

Adds the Attest type and all the different attest info types.

[ionut-arm]

🤯 That's a lot of new types, thanks!! Looks pretty good overall, had just a few comments/questions.

I'm also curious, I thought there was at least one place where one of the FFI types is used, TPM2B_ATTEST, I think. Did you not want to update that yet?

[wiktor-k]

Quite a nice collection of types.
They are currently not used by any context methods? Just curious how would they fit in the larger scheme of things here...

[Superhepper]

From a pure functionality point of view there is little difference. But the new traits are more explicit, the data they produce and consumes are not just any bytes it is specifically the bytes that are produced or consumed by the Tss2_MU_* functions for each individual type.

[wiktor-k]

Good point. Thanks for the explanation @Superhepper and @ionut-arm 👍!

[Superhepper]

The types will be used later by context method implementation of TPM2_Certify for example. I actually took some code from the @ionut-arm Certify PR and made the types more 'complete'.

[Superhepper]

🤯 That's a lot of new types, thanks!! Looks pretty good overall, had just a few comments/questions.

I'm also curious, I thought there was at least one place where one of the FFI types is used, TPM2B_ATTEST, I think. Did you not want to update that yet?

I was so focused on the Attest type and all the info types that I did not even think of to check if the TPM2B_ATTEST or TPMS_ATTEST was used any where. But I fixed that now.

[ionut-arm]

👍🏻

[Superhepper]

@wiktor-k: Is there something you would like to be changed before this can be merged?

[wiktor-k]

I've re-read it all and the only place I'm less-than-super-positive is unsafe { buffer.set_len(offset as usize) };. I'm wondering if truncate is not sufficient in this case? Maybe I'm paranoid but I wouldn't want the vector to contain some random memory in case offset is bigger than the initial capacity.

If you think it's good as it is I won't block it though :)

[Superhepper]

I've re-read it all and the only place I'm less-than-super-positive is unsafe { buffer.set_len(offset as usize) };. I'm wondering if truncate is not sufficient in this case? Maybe I'm paranoid but I wouldn't want the vector to contain some random memory in case offset is bigger than the initial capacity.

If you think it's good as it is I won't block it though :)

Well truncate wont work here because the vector can in this case not know the number of bytes that have been written to it.

What can be done is to allocate an array with a maximum size and write the data to it and then convert a slice of that array into an vector. It would require some extra copying. But it might be worth it in order to avoid the unsafe part.

[wiktor-k]

Nah, I think it's fine it just looks weird on first sight. The same issue happens in cryptoki that you're supposed to pass a buffer big enough end then cut it. I was also thinking about running drop on elements outside of len but since this is just u8s then there's nothing to worry about.

This is good for me after your explanations, not sure if rewriting to use arrays would be the best use of your time :)

[Superhepper]

I actually come up with a way to use truncate instead. Will change it in one sec.

[wiktor-k]

Ha, very cool! One less unsafe thing to worry about. Thanks for taking the extra steps for safety @Superhepper. 👍