Messages in this thread | | | Date | Tue, 22 Nov 2022 04:32:18 -0600 | Subject | Re: [PATCH Part2 v6 14/49] crypto: ccp: Handle the legacy TMR allocation when SNP is enabled | From | "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. >
| |