Re: [PATCH Part2 v6 14/49] crypto: ccp: Handle the legacy TMR allocation when SNP is enabled

[Kalra, Ashish]

Hello Boris,

On 11/22/2022 4:17 AM, Borislav Petkov wrote:
> On Mon, Nov 21, 2022 at 06:37:18PM -0600, Kalra, Ashish wrote:
> > I agree, but these pages are not in the right state to be released back to
>
> Which pages exactly?
>
> Some pages' state has really changed underneath or you've given the
> wrong range?
>
> > It might be a user/sev-guest error, but these pages are now unsafe to use.
> > So is a kernel panic justified here, instead of not releasing the pages back
> > to host and logging errors for the same.
>
> Ok, there are two cases:
>
> * kernel error: I guess a big fat warning is the least we can issue
> here. Not sure about panic considering this should almost never happen
> and a warning would allow for people to catch dumps and debug the issue.
>
> * firmware error: I don't think you can know that that is really
> the case on a production system without additional fw debugging
> capabilities. Dumping a warning would be the least we can do here too,
> to signal that something's out of the ordinary and so people can look
> into it further.

Please note that in both cases, these non-reclaimed pages cannot be 
freed/returned back to the page allocator. Anytime the kernel accesses 
these pages it will cause a panic or host process crash.

So along with warning, the pages will be added to a leaked pages list, 
but there is no poisoning or anything, only need to ensure that these 
pages are not touched/accessed again.

Thanks,
Ashish

> So yeah, a big fat warning is a good start. And then you don't need any
> memory poisoning etc gunk.