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@xxxxxxxxxxxxx/ > > 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
