On Mon, Feb 07, 2022 at 08:41:47AM -0600, Brijesh Singh wrote:

Randy asked me similar question on v7, and here is my response to it.

https://lore.kernel.org/linux-mm/e6b412e4-f38e-d212-f52a-e7bdc9a26eff@infradead.org/ (local)

Let me know if you still think that we should make it 'n'. I am not dead
against it but I have feeling that once distro's starts building SNP aware
guest kernel, then we may get asked to enable it by default so that
attestation report can be obtained by the initial ramdisk.

Well, let's see:

$ make oldconfig
...

#
# No change to .config
#
$

So it didn't even ask me. Because

# CONFIG_VIRT_DRIVERS is not set

so what's the point of this "default y"?

If the distros are your worry, then you probably will have to ask
them to do so explicitly anyway because at least we edit our configs
ourselves and decide what to enable or what not.

After this condition is met, a guest will no longer get the attestation
report. It's up to the userspace to reboot the guest or continue without
attestation.

The only thing that will reset the counter is re-launching the guest to go
through the entire PSP initialization sequence once again.

Well, but you need to explain that somewhere to the guest owners.
I guess either here in that error message or in some higher-level
glue which will do the attestation. Just saying that some counter has
overflown is not very user-friendly, I'd say.

Yep, it need to protect more stuff.

We allocate a shared buffers (request, response, cert-chain) that gets
populated before issuing the command, and then we copy the result from
reponse shared to callers buffer after the command completes. So, we also
want to ensure that the shared buffer is not touched before the previous
ioctl is finished.

So you need to rename that mutex and slap a comment above it what it
protects.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette