Re: [PATCH RFC 0/3] security: ima: support TSM measurement registers

[GONG Ruiqi <gongruiqi1@huawei.com>]

On 10/13/2026 4:41 PM, Yeoreum Yun wrote:
>> On 10/1/2026 10:24 PM, Yeoreum Yun wrote:
>>> Hi Roberto,
>>>
>>>> On Thu, 2026-10-01 at 13:27 +0200, Roberto Sassu wrote:
>>>>> On Wed, 2026-09-30 at 14:43 +0100, Yeoreum Yun wrote:
>>>>>> Confidential computing guests without a TPM can use TSM measurement
>>>>>> registers to record IMA measurement digests instead of TPM PCRs.
>>>>
>>>> + Gong Ruiqi, of course.
>>>>
>>>> Roberto
>>
>> Hi Roberto,
>>
>> [...]Thank you for involving me!
>>
>>>>
>>>>> Hi Yeoreum
>>>>>
>>>>> a similar patch set has been sent to the linux-integrity mailing list:
>>>>>
>>>>> https://lore.kernel.org/linux-integrity/20250630125928.765285-1-gongruiqi1@huawei.com/
>>>>>
>>>>> Could you please work with Gong Ruiqi to have a unified proposal?
>>>>>
>>>>> Thanks
>>>>>
>>>>> Roberto
>>>>>
>>>
>>> Thanks for letting me know and I think the proposal is almost the same
>>> with the different terminology only.
>>>
>>> @Gong, what do you think?
>>
>> Hi Yeoreum,
>>
>> Nice to see this topic picked up again — I'm glad the IMA RoT framework
>> series I posted last year is still of interest.
>>
>> Yes, I'd be happy to work with you on a unified proposal. It's been a
>> while since I last worked on that series, so I'll first revisit my
>> previous patch set, and then follow up with you to discuss the code details.
>>
>> Looking forward to working with you.
>>
>> BR,
>> Ruiqi
> 
> Hi Ruiqi :)
> 
> Thanks for replying and I'm happy with you too.
> However, I think we need to rework based on the Jiri's patch [0].
> 
> Any thought?

Hi Yeoreum,

I'd rather not base our work on Jiri's patch at this stage: it is
a pre-RFC draft of the new attestation subsystem, whose design is
itself still in progress. Building upon it instead of current
mainline would be quite risky — we would be rebasing on a moving
target, and merging would be blocked until the whole framework
lands, which is realistically far off.

I'd suggest we develop the proposal on current mainline, and
switch to the new attestation subsystem once it lands. As I
understand it, for us that is mostly just a matter of switching
to a different set of APIs.

BR,
Ruiqi

> 
> Link: [0] https://github.com/jpirko/linux_mlxsw/tree/wip_attestation_pre_rfc_draft1 
> 
>