[PATCH 2/3] gfp: mm: introduce __GFP_NOINIT
Kees Cook
keescook at chromium.org
Tue Apr 23 19:14:36 UTC 2019
On Thu, Apr 18, 2019 at 9:52 AM Dave Hansen <dave.hansen at intel.com> wrote:
>
> On 4/18/19 8:42 AM, Alexander Potapenko wrote:
> > diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
> > index be84f5f95c97..f9d1f1236cd0 100644
> > --- a/kernel/kexec_core.c
> > +++ b/kernel/kexec_core.c
> > @@ -302,7 +302,7 @@ static struct page *kimage_alloc_pages(gfp_t gfp_mask, unsigned int order)
> > {
> > struct page *pages;
> >
> > - pages = alloc_pages(gfp_mask & ~__GFP_ZERO, order);
> > + pages = alloc_pages((gfp_mask & ~__GFP_ZERO) | __GFP_NOINIT, order);
> > if (pages) {
> > unsigned int count, i;
>
> While this is probably not super security-sensitive, it's also not
> performance sensitive.
It is, however, a pretty clear case of "and then we immediately zero it".
> These sl*b ones seem like a bad idea. We already have rules that sl*b
> allocations must be initialized by callers, and we have reasonably
> frequent bugs where the rules are broken.
Hm? No, this is saying that the page allocator can skip the auto-init
because the slab internals will be doing it later.
> Setting __GFP_NOINIT might be reasonable to do, though, for slabs that
> have a constructor. We have much higher confidence that *those* are
> going to get initialized properly.
That's already handled in patch 1.
--
Kees Cook
More information about the Linux-security-module-archive
mailing list