From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yw1-f180.google.com (mail-yw1-f180.google.com [209.85.128.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 97DB630DD2E for ; Tue, 25 Nov 2025 18:58:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.180 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764097116; cv=none; b=dj/I5ffQeMtv+sRx2yt8T8KnO9YgcDlT1KyWrkZoud6Fcv3JFIVYdr3hP8w5cG6elnaqPMf/5uZfMrRGf5OmysEkuwT9vH8i+j4R3IcYLsmlcXjAgC2oAqrE5iKISEnJOoTGtmwRGA9hfS80HLaC8fZdHM46C6LMWQkc1w7jBzI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764097116; c=relaxed/simple; bh=P6buRtJzpa25T5VxcH/q8Nt4p9GSLN8WnUDho5tkVtw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=erxKgXtu8XFTIh4/43Vj2DK8ZDwnuBbb7ZKQMpwQcXTetX02CBlcRGRVgPdihXNouRSUpywkXhNWK7rxoap+r4ebZaOTHvX2TH7zh5KFoi5Xiy4hSIx6sscadA0e1NQNkGhUFluJlLyVAmbIzH40fSzEMUm3pI9t8zkQYZuyXuA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=jZTifSKX; arc=none smtp.client-ip=209.85.128.180 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="jZTifSKX" Received: by mail-yw1-f180.google.com with SMTP id 00721157ae682-787e35ab178so56503667b3.2 for ; Tue, 25 Nov 2025 10:58:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1764097113; x=1764701913; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=1+zeOdZZaF4BJyqy5kMaeSWqNQvCyQPG+omQ/g0Gj7k=; b=jZTifSKXL5ZytmMfbS6mrxQUv8melgGuWIzYiJrJSdf+MHJbjTiTTTYOxxEstOOZUW 3iUPA2fOx4Vb1D028IewvBS7KSEANUIrZbdUEZugwfYQh6U/SHeClWDpl5X6n56NRiL1 aX+qEq2ecKBjCC5imUP+yPAUaFL1gprO62dIpCSw8PzI04lKHS9dUIVozhmG7px+hE3c zKFlHtLFXjKqfJPvrAWy9SWJgWwS5tDnhoe9csWZMf4bfsrbGdZH0hwgApYZh4TUtamH tHcFdeFvGCs4NP4yPSu1Csu6Da/lVsE+lJpldhyrzoP6JQGpqEoUn0KbUwIcxWnZYul2 /urA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764097113; x=1764701913; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=1+zeOdZZaF4BJyqy5kMaeSWqNQvCyQPG+omQ/g0Gj7k=; b=jisBXlAHRetErnp9rKxSgjsLxVmG8nf+dgMjfbHRLon/Litb5phgLIiJZpIdjgUVq/ oejncur4jmH2YILW2QBACGcWh9O0FdyG/G08PgWgX5CMpjEy6KN426uzj74+yXEg2Xan 0be+XKVwKx9ad3zO+zTGOhiQgFXMDTRxptLEW1q5ClAfoF2fSGyFGxT4VVLngTTxQfSI N/CAp/1fq8T8Uem5bienoQjJpDvo+URccKnp1fSPT7MPF1WXDoUKxIW6UnZA1iQFdOdX LjoNBYnA1kUTFfNP3ieIQmS35/NBbnC0qMJAFVm2BPUxa43G1MBHguh2PYsII3Qwj523 a1AA== X-Forwarded-Encrypted: i=1; AJvYcCXQKsZ1Xdu0Gmhe0beY9IkX9XtEUKS2P8X4cfVS4ylpRXGCw7NCMTZI2r9l+8qYII9QDCYMTnRQmzGfxdI=@vger.kernel.org X-Gm-Message-State: AOJu0YxSBo6li8MQtxE5WDYkFnyPo0SjcxCSyug8V8UJf7cg08bD6ge9 VldO6i+Wm+bsHTRYnketZHlHHl1gEoiur4B9/E9MocTdvF9/LNiR2RuB X-Gm-Gg: ASbGncv9Oh0y7p8uMRO5cG1HBHMHD0IoPz7pgY5k1ciOflcCP6hhWNeZTrkzbEB4G0K /aoRKXVL8c2rOgiol01hR9qLWkvUhKmWhBHioyYeU+n3Xk9QScQK4EDNkKYNfwYGuRwnQEwsMLq Tfof3KUaJj9+LvKk0tjKFYUKIYIdeLYRXswnOkaCsw7yJSsg+J3Ceqc2MeKlyWhVehWSp8UlLpr fpooFqkq+WLU2ST3FcsU94m4clXUdvJrhUXKRGlvCeCfbSLkAwoqMfm/BfEVvgCkzxjvkfy0lfa R3jDfdjeYrVXQqR7Ws9MXk04qkvULCmc4G0ny4sK869/098ZuF36rrEAQzeqC/j92pKzsTmmrJs 9I0ePkW9jON/egPQq1ppMl2k5mZRKh1t5GVmRDtfm8fc+fYxxGayR09NC8jKCuaHiQLTeXtaYwm K4dS0iIbQ= X-Google-Smtp-Source: AGHT+IEd3fC2WDscBWmJaJ6t/VrtBvr4q279/8luMzo4kTWQtijZrJPqNt4WkAAB0deXmKVtpnwI3g== X-Received: by 2002:a05:690c:45c4:b0:788:17d2:be64 with SMTP id 00721157ae682-78a8b491d25mr140972287b3.26.1764097113523; Tue, 25 Nov 2025 10:58:33 -0800 (PST) Received: from localhost ([2a03:2880:25ff:72::]) by smtp.gmail.com with ESMTPSA id 00721157ae682-78a9a39101fsm35977827b3.43.2025.11.25.10.58.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 25 Nov 2025 10:58:33 -0800 (PST) From: Joshua Hahn To: Vlastimil Babka Cc: Michal Hocko , Kees Cook , "Gustavo A. R. Silva" , "linux-hardening@vger.kernel.org" , Andrew Morton , Mike Rapoport , linux-kernel@vger.kernel.org, linux-mm@kvack.org, kernel-team@meta.com Subject: Re: [PATCH v2 2/2] mm/mm_init: decouple page checking and init_on_{alloc, free} Date: Tue, 25 Nov 2025 10:58:18 -0800 Message-ID: <20251125185818.1586946-1-joshua.hahnjy@gmail.com> X-Mailer: git-send-email 2.47.3 In-Reply-To: <5d0c582f-7e1a-4623-90d9-1dd6db443473@suse.cz> References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit On Tue, 25 Nov 2025 19:06:53 +0100 Vlastimil Babka wrote: > On 11/25/25 09:45, Michal Hocko wrote: > > On Mon 24-11-25 14:54:07, Joshua Hahn wrote: > >> init_on_alloc and init_on_free protect the kernel by initializing > >> allocated and freed pages to 0 on allocation time / deletion. > >> Commit 700d2e9a36b93601270c1e15550acde2521386c5 ("mm, page_alloc: reduce > >> page alloc/free sanity checks") removed page checking from hot pcp > >> drain and refill paths, and instead coupled it with CONFIG_DEBUG_VM, > >> debug_pagealloc, page poisoning, and init_on_{alloc, free}. > >> > >> As the commit suggests, the first three turn the kernel into a debug > >> kernel, while the last hardens the kernel against leaking sensitive memory. > >> While enabling page checking is relatively low-cost and tying it > >> together with page initialization is not unreasonable, it does feel like > >> a bit of a side-effect, rather than an obvious consequence. > >> > >> With page checking now pulled out as a boot time parameter that can be > >> set independently, let's decouple page checking and init_on_alloc and > >> init_on_free. > >> > >> As a direct side effect, systems that have init_on_alloc or init_on_free > >> will no longer have page checking enabled by default; they will either > >> have to pass the check_pages boot parameter, build the kernel with > >> CONFIG_DEBUG_VM, or enable debug_pagealloc / page poisoning. > > > > How come this will not break existing users? What is an actual upside to > > get for the risk involved? Hello Michal, Vlastimil > +Cc hardening people for input if they are fine with the decoupling and if > docs for hardening recommendations or something similar needs updating Thank you! > The upside is mainly reducing the side effects i.e. being more explicit than > implicit. In practice I'd however assume people running init_on_alloc/free > and paying the cost also want to do page flags checking anyway. The more > important patch here is 1/2. I agree with all of this. Maybe an alternate approach is not to decouple the flags, but to make their relationship more explicit in Documentation. Currently, userspace doesn't have much visibility into this relationship, so an additional line in Documentation/admin-guide/kernel-parameters could achieve the same desired outcome. I'll also let the hardning folks comment on this before sending out v3 in case they have additional requests or ideas for this. Thank you all for your review! Joshua