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=-3.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no 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 6CA99C433DF for ; Wed, 19 Aug 2020 23:36:18 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id ED7882076E for ; Wed, 19 Aug 2020 23:36:17 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="RYffqW5j" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org ED7882076E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=chromium.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 0F04C6B0003; Wed, 19 Aug 2020 19:36:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0A0CC6B0005; Wed, 19 Aug 2020 19:36:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EF8186B0062; Wed, 19 Aug 2020 19:36:16 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0228.hostedemail.com [216.40.44.228]) by kanga.kvack.org (Postfix) with ESMTP id DB5456B0003 for ; Wed, 19 Aug 2020 19:36:16 -0400 (EDT) Received: from smtpin04.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 9642E3626 for ; Wed, 19 Aug 2020 23:36:16 +0000 (UTC) X-FDA: 77168929152.04.cars06_5c01ea82702c Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin04.hostedemail.com (Postfix) with ESMTP id 6A9468002CF4 for ; Wed, 19 Aug 2020 23:36:16 +0000 (UTC) X-HE-Tag: cars06_5c01ea82702c X-Filterd-Recvd-Size: 4088 Received: from mail-pl1-f196.google.com (mail-pl1-f196.google.com [209.85.214.196]) by imf12.hostedemail.com (Postfix) with ESMTP for ; Wed, 19 Aug 2020 23:36:15 +0000 (UTC) Received: by mail-pl1-f196.google.com with SMTP id g15so161975plj.6 for ; Wed, 19 Aug 2020 16:36:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=OL8pogAZ7nK/GHwOhHpYX84wczTBnNXhUKszoax97yw=; b=RYffqW5j0gjcmqcAj0G4MNruh3ppWqpBsZ8QlvxrvGV6E83CWwux4WS6qnUuvz51sr E4NgGnt7fx4sHD6mIqOgU+uA98mMhWEO2MXccxzbH4uSQ2urHK6W+Zr7hPVMgV/c8r+g 0DTIsord8MCQKQPhvMj67W6EgsU2F5nK7rUZw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=OL8pogAZ7nK/GHwOhHpYX84wczTBnNXhUKszoax97yw=; b=tm+cKggOEd4A61lGwr2do4NmUuTLC7JhBjH/MI8ED5lq+uJ2XP27X1zrFju2bOPmWu gicYNy01VlkuNpGUmrN85QQKOllp3YPkMnXyEfEO99HJWzjKAh1M1+YgP9wy1dcamolr 22UsNlLXutGcHwU1WnqPj4nHoSQqGolHr8L4pCeawYcKzqV/7/PLDLkcLF4qEHwR8Z1M 3JOomZY2FbZIFM0cvYZNoXBzVX2bLf0Su9KiKiMeIPyKFxGa3o95gSxf7ACUjqfFAJDV gDuJwmBbUPI4RWSTKyie9CfMbamthD/C2Li0/TvfeAH/x8DBKo4PdRCsClf3Z8wLFrX7 7rXA== X-Gm-Message-State: AOAM532dc9TZIklWpSJ04pYclwjdZ1KDYMUIkR6H0A+n/85mJbzQ/kUZ iEKj+cA8GeXcenSTqU7BIhPH3A== X-Google-Smtp-Source: ABdhPJztG561lgarz0fyj0g5MgwaALC3qNQDwRg7Mg7XodZzm8ie+lc4uJ10jF+RtiVvGy+Gslmjlw== X-Received: by 2002:a17:90a:c682:: with SMTP id n2mr239820pjt.72.1597880175006; Wed, 19 Aug 2020 16:36:15 -0700 (PDT) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id e8sm327961pfd.34.2020.08.19.16.36.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 19 Aug 2020 16:36:11 -0700 (PDT) Date: Wed, 19 Aug 2020 16:36:10 -0700 From: Kees Cook To: Jirka Hladky Cc: Alexander Potapenko , kernel-hardening@lists.openwall.com, linux-mm@kvack.org, linux-security-module@vger.kernel.org Subject: Re: init_on_alloc/init_on_free boot options Message-ID: <202008191626.1420C63231@keescook> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 6A9468002CF4 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam04 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, Aug 20, 2020 at 12:18:33AM +0200, Jirka Hladky wrote: > Could you please help me to clarify the purpose of init_on_alloc=1 > when init_on_free is enabled? It's to zero memory at allocation time. :) (They are independent options.) > If I get it right, init_on_free=1 alone guarantees that the memory > returned by the page allocator and SL[AU]B is initialized with zeroes. No, it's guarantees memory freed by the page/slab allocators are zeroed. > What is the purpose of init_on_alloc=1 in that case? We are zeroing > memory twice, or am I missing something? If you have both enabled, yes, you will zero twice. (In theory, if you have any kind of Use-After-Free/dangling pointers that get written through after free and before alloc, those contents wouldn't strictly be zero at alloc time without init_on_alloc. But that's pretty rare. I wouldn't expect many people to run with both options enabled; init_on_alloc is more performance-friendly (i.e. cache-friendly), and init_on_free minimizes the lifetime of stale data in memory. It appears that the shipping kernel defaults for several distros (Ubuntu, Arch, Debian, others?) and devices (Android, Chrome OS, others?) are using init_on_alloc=1. Will Fedora and/or RedHat be joining this trend? :) -- Kees Cook