lkml.org 
[lkml]   [2022]   [Dec]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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.

\
 
 \ /
  Last update: 2023-03-26 23:23    [W:0.070 / U:0.484 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site