lkml.org 
[lkml]   [2022]   [Nov]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH Part2 v6 14/49] crypto: ccp: Handle the legacy TMR allocation when SNP is enabled
From
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.
>

\
 
 \ /
  Last update: 2022-11-22 11:38    [W:0.187 / U:0.048 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site