All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kees Cook <kees@kernel.org>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: "Christoph Lameter (Ampere)" <cl@gentwo.org>,
	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
Date: Mon, 10 Jun 2024 14:37:25 -0700	[thread overview]
Message-ID: <202406101435.DFBCA953B@keescook> (raw)
In-Reply-To: <8b844d71-01f1-472b-a63a-4c9cdb26e9ef@suse.cz>

On Mon, Jun 10, 2024 at 10:54:26PM +0200, Vlastimil Babka wrote:
> On 6/10/24 7:07 PM, Christoph Lameter (Ampere) wrote:
> > On Fri, 7 Jun 2024, Chengming Zhou wrote:
> > 
> >> There are two inconsistencies in check_object(), which are alignment
> >> padding checking and object padding checking. We only print the error
> >> messages but don't return 0 to tell callers that something is wrong
> >> and needs to be handled. Please see alloc_debug_processing() and
> >> free_debug_processing() for details.
> > 
> > If the error is in the padding and the redzones are ok then its likely 
> > that the objects are ok. So we can actually continue with this slab page 
> > instead of isolating it.
> > 
> > We isolate it in the case that the redzones have been violated because 
> > that suggests someone overwrote the end of the object f.e. In that case 
> > objects may be corrupted. Its best to isolate the slab and hope for the 
> > best.
> > 
> > If it was just the padding then the assumption is that this may be a 
> > scribble. So clean it up and continue.

"a scribble"? :P If padding got touched, something has the wrong size
for an object write. It should be treated just like the redzones. We
want maximal coverage if this checking is enabled.

> Hm is it really worth such nuance? We enabled debugging and actually hit a
> bug. I think it's best to keep things as much as they were and not try to
> allow further changes. This e.g. allows more detailed analysis if somebody
> later notices the bug report and decides to get a kdump crash dump (or use
> drgn on live system). Maybe we should even stop doing the restore_bytes()
> stuff, and prevent any further frees in the slab page to happen if possible
> without affecting fast paths (now we mark everything as used but don't
> prevent further frees of objects that were actually allocated before).
> 
> 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)

Yeah, if we're doing these checks, we should do the checks fully.
Padding is just extra redzone. :)

-- 
Kees Cook


  reply	other threads:[~2024-06-10 21:37 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-07  8:40 [PATCH v3 0/3] slab: fix and cleanup of slub_debug Chengming Zhou
2024-06-07  8:40 ` [PATCH v3 1/3] slab: make check_object() more consistent Chengming Zhou
2024-06-07  8:58   ` Vlastimil Babka
2024-06-10 17:07   ` Christoph Lameter (Ampere)
2024-06-10 20:54     ` Vlastimil Babka
2024-06-10 21:37       ` Kees Cook [this message]
2024-06-11 22:52       ` Christoph Lameter (Ampere)
2024-06-12 18:39         ` Kees Cook
2024-06-14  2:40         ` Chengming Zhou
2024-06-17  9:51           ` Vlastimil Babka
2024-06-17 10:29             ` Chengming Zhou
2024-06-17 11:08               ` Vlastimil Babka
2024-06-18 16:57           ` Christoph Lameter (Ampere)
2024-06-07  8:40 ` [PATCH v3 2/3] slab: don't put freepointer outside of object if only orig_size Chengming Zhou
2024-06-07  8:40 ` [PATCH v3 3/3] slab: delete useless RED_INACTIVE and RED_ACTIVE Chengming Zhou
2024-06-07  9:27 ` [PATCH v3 0/3] slab: fix and cleanup of slub_debug Vlastimil Babka

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=202406101435.DFBCA953B@keescook \
    --to=kees@kernel.org \
    --cc=42.hyeyoo@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=chengming.zhou@linux.dev \
    --cc=cl@gentwo.org \
    --cc=feng.tang@intel.com \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=penberg@kernel.org \
    --cc=rientjes@google.com \
    --cc=roman.gushchin@linux.dev \
    --cc=vbabka@suse.cz \
    --cc=zhouchengming@bytedance.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.