Received-SPF: pass (google.com: domain of linux-kernel+bounces-212098-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Date: Wed, 12 Jun 2024 11:39:19 -0700
From: Kees Cook <kees@kernel.org>
To: "Christoph Lameter (Ampere)" <cl@linux.com>
Cc: Vlastimil Babka <vbabka@suse.cz>,
	Chengming Zhou <chengming.zhou@linux.dev>,
	Pekka Enberg <penberg@kernel.org>,
	David Rientjes <rientjes@google.com>,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Roman Gushchin <roman.gushchin@linux.dev>,
	Hyeonggon Yoo <42.hyeyoo@gmail.com>,
	Feng Tang <feng.tang@intel.com>, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org, zhouchengming@bytedance.com
Subject: Re: [PATCH v3 1/3] slab: make check_object() more consistent
Message-ID: <202406121135.A3900578BF@keescook>
References: <20240607-b4-slab-debug-v3-0-bb2a326c4ceb@linux.dev>
 <20240607-b4-slab-debug-v3-1-bb2a326c4ceb@linux.dev>
 <63da08b7-7aa3-3fad-55e6-9fc3928a49de@gentwo.org>
 <8b844d71-01f1-472b-a63a-4c9cdb26e9ef@suse.cz>
 <e93fc5a6-434f-376c-a819-353124da053d@linux.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <e93fc5a6-434f-376c-a819-353124da053d@linux.com>

On Tue, Jun 11, 2024 at 03:52:49PM -0700, Christoph Lameter (Ampere) wrote:
> On Mon, 10 Jun 2024, Vlastimil Babka wrote:
> 
> > Even if some security people enable parts of slub debugging for security
> > people it is my impression they would rather panic/reboot or have memory
> > leaked than trying to salvage the slab page? (CC Kees)
> 
> In the past these resilience features have been used to allow the continued
> operation of a broken kernel.
> 
> So first the Kernel crashed with some obscure oops in the allocator due to
> metadata corruption.
> 
> One can then put a slub_debug option on the kernel command line which will
> result in detailed error reports on what caused the corruption. It will also
> activate resilience measures that will often allow the continued operation
> until a fix becomes available.

Sure, as long as it's up to the deployment. I just don't want padding
errors unilaterally ignored. If it's useful, there's the
CHECK_DATA_CORRUPTION() macro. That'll let a deployment escalate the
issue from WARN to BUG, etc.

-- 
Kees Cook