From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.6 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 37CA5C43613 for ; Fri, 21 Jun 2019 09:12:04 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 0D72C208C3 for ; Fri, 21 Jun 2019 09:12:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1561108324; bh=vq3TjYDhQtCRaQcPZKL7ZGrFfUOOLFtRDLxM8NdeTJM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=KrM/Ow29Zg+d03gDV0GCki5UFIRNl2fueC0+uOKR/00uk+Tcv7nUZshZzVDgvaSM5 EHuMrfkN/e2pyOFKHNYdYJFdZR4Cvl6u8uu0lYkS2PllIfYMHAuG3lLppZfwUSI13o 4ZdF1SoZobC3SkjBJ5Z9Uv7KhnJ/N7kP17XM7wZ8= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726232AbfFUJMD (ORCPT ); Fri, 21 Jun 2019 05:12:03 -0400 Received: from mx2.suse.de ([195.135.220.15]:40646 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726218AbfFUJMD (ORCPT ); Fri, 21 Jun 2019 05:12:03 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id DA07AAD17; Fri, 21 Jun 2019 09:12:01 +0000 (UTC) Date: Fri, 21 Jun 2019 11:11:59 +0200 From: Michal Hocko To: Alexander Potapenko Cc: Andrew Morton , Christoph Lameter , Kees Cook , Masahiro Yamada , James Morris , "Serge E. Hallyn" , Nick Desaulniers , Kostya Serebryany , Dmitry Vyukov , Sandeep Patil , Laura Abbott , Randy Dunlap , Jann Horn , Mark Rutland , Marco Elver , Linux Memory Management List , linux-security-module , Kernel Hardening Subject: Re: [PATCH v7 1/2] mm: security: introduce init_on_alloc=1 and init_on_free=1 boot options Message-ID: <20190621091159.GD3429@dhcp22.suse.cz> References: <20190617151050.92663-1-glider@google.com> <20190617151050.92663-2-glider@google.com> <20190621070905.GA3429@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: owner-linux-security-module@vger.kernel.org Precedence: bulk List-ID: On Fri 21-06-19 10:57:35, Alexander Potapenko wrote: > On Fri, Jun 21, 2019 at 9:09 AM Michal Hocko wrote: [...] > > > diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c > > > index fd5c95ff9251..2f75dd0d0d81 100644 > > > --- a/kernel/kexec_core.c > > > +++ b/kernel/kexec_core.c > > > @@ -315,7 +315,7 @@ static struct page *kimage_alloc_pages(gfp_t gfp_mask, unsigned int order) > > > arch_kexec_post_alloc_pages(page_address(pages), count, > > > gfp_mask); > > > > > > - if (gfp_mask & __GFP_ZERO) > > > + if (want_init_on_alloc(gfp_mask)) > > > for (i = 0; i < count; i++) > > > clear_highpage(pages + i); > > > } > > > > I am not really sure I follow here. Why do we want to handle > > want_init_on_alloc here? The allocated memory comes from the page > > allocator and so it will get zeroed there. arch_kexec_post_alloc_pages > > might touch the content there but is there any actual risk of any kind > > of leak? > You're right, we don't want to initialize this memory if init_on_alloc is on. > We need something along the lines of: > if (!static_branch_unlikely(&init_on_alloc)) > if (gfp_mask & __GFP_ZERO) > // clear the pages > > Another option would be to disable initialization in alloc_pages() using a flag. Or we can simply not care and keen the code the way it is. First of all it seems that nobody actually does use __GFP_ZERO unless I have missed soemthing - kimage_alloc_pages(KEXEC_CONTROL_MEMORY_GFP, order); # GFP_KERNEL | __GFP_NORETRY - kimage_alloc_pages(gfp_mask, 0); - kimage_alloc_page(image, GFP_KERNEL, KIMAGE_NO_DEST); - kimage_alloc_page(image, GFP_HIGHUSER, maddr); but even if we actually had a user do we care about double intialization for something kexec related? It is not any hot path AFAIR. -- Michal Hocko SUSE Labs