Messages in this thread | | | Date | Fri, 30 Dec 2022 14:01:04 -0800 (PST) | From | David Rientjes <> | Subject | Re: [PATCH] crypto: ccp - Limit memory allocation in SEV_GET_ID2 ioctl |
| |
On Wed, 28 Dec 2022, Herbert Xu wrote:
> On Tue, Dec 27, 2022 at 05:42:31PM -0800, David Rientjes wrote: > > > > The goal was to be more explicit about that, but setting __GFP_NOWARN > > would result in the same functional behavior. If we're to go that route, > > it would likely be best to add a comment about the limitation. > > > > That said, if AMD would prefer this to be an EINVAL instead of a ENOMEM by > > introducing a more formal limitation on the length that can be used, that > > would be preferred so that we don't need to rely on the page allocator's > > max length to enforce this arbitrarily. > > Ideally the limit should be set according to the object that > you're trying to allocate. But if that is truly unlimited, > and you don't want to see a warning, then GFP_NOWARN seems to > fit the bill. >
AMD would be able to speak authoritatively on it, but I think the length of the ID isn't to be assumed by software because it will likely change later.
I don't think there's an active vulnerability with the currnet code so we can likely drop stable@vger.kernel.org for this. The kzalloc() will fail if you try to allocate over 2MB. If you try to allocate >32KB, the page allocator will attempt to reclaim but won't oom kill. If you try to allocate <=32KB, there's the potential for oom kill if nothing is reclaimable, but if memory is that scarce I think we have bigger problems.
So __GFP_NOWARN will work, but I also think it's subtle enough that it warrants being coupled with a comment.
| |