Re: [PATCH v3] crypto/ccp: Introduce SNP_VERIFY_MITIGATION command

From: Tom Lendacky

Date: Thu May 21 2026 - 16:04:30 EST


On 5/21/26 10:05, Tycho Andersen wrote:
> On Thu, May 21, 2026 at 08:12:52AM -0500, Tom Lendacky wrote:
>>> Now, with unregister no longer protected by sev_cmd_mutex, a concurrent init
>>> can race with shutdown on the sysfs lifetime like so:
>>
>> Can it? Can init and shutdown race? Isn't that part of module load /
>> unload, I'm not sure how they can race...
>
> That's only true after
> https://lore.kernel.org/all/20260504165147.1615643-5-tycho@xxxxxxxxxx/
> right? Before that, if the first init failed, you could trigger a
> re-init via ioctl(), and presumably trigger the race sashiko is
> complaining about by spamming ioctl() + sysfs writes on separate
> threads.
>
>>> t1 | t2
>>> ---------------------------------- | ----------------------------------
>>> sev_firmware_shutdown() | sev_platform_init()
>>> unregister_verify_mitigation() | register_verify_mitigation()
>>> sysfs_remove_group() | sysfs_create_group()
>>>
>>> Both sides touch sev->verify_mit without serialization. The same race also
>>> exists for init vs init which is no longer covered by sev_cmd_mutex once
>>> register moves outside it.
>>
>> I don't think you can have init vs init race, can you? This just all seems
>> odd to me. Have you created all these race scenarios to test this out?
>>
>> Would putting the regsiter/unregister under the sev_cmd_mutex and then
>> taking the sev_cmd_mutex upon entry to _show()/_store() fix all this?
>> After obtaining the mutex in _show()/_store(), you check for
>> sev->verify_mit and return an error if NULL. Then you can use the
>> __sev_do_cmd_locked() to issue any commands.
>
> As long as sysfs_remove_group() happens before
> __sev_firmware_shutdown() it seems like it should be fine since sysfs
> will do its own synchronization. IIUC we might not need this locking
> at all assuming the above is applied?

That's what I'm thinking. I'll let Pratik confirm.

Thanks,
Tom

>
> Tycho