From: Alexander Popov <email@example.com>
To: Kees Cook <firstname.lastname@example.org>
Cc: Christopher Lameter <email@example.com>,
Matthew Wilcox <firstname.lastname@example.org>,
Pekka Enberg <email@example.com>,
David Rientjes <firstname.lastname@example.org>,
Joonsoo Kim <email@example.com>,
Andrew Morton <firstname.lastname@example.org>,
Subject: Re: [PATCH 1/1] mm/slub.c: add a naive detection of double free or corruption
Date: Wed, 19 Jul 2017 11:38:57 +0300 [thread overview]
Message-ID: <email@example.com> (raw)
On 18.07.2017 23:04, Kees Cook wrote:
> On Tue, Jul 18, 2017 at 12:56 PM, Alexander Popov <firstname.lastname@example.org> wrote:
>> On 17.07.2017 22:11, Kees Cook wrote:
>>> Let's merge this with the proposed CONFIG_FREELIST_HARDENED, then the
>>> performance change is behind a config, and we gain the rest of the
>>> freelist protections at the same time:
>> Hello Kees,
>> If I change BUG_ON() to VM_BUG_ON(), this check will work at least on Fedora
>> since it has CONFIG_DEBUG_VM enabled. Debian based distros have this option
>> disabled. Do you like that more than having this check under
> I think there are two issues: first, this should likely be under
> CONFIG_FREELIST_HARDENED since Christoph hasn't wanted to make these
> changes enabled by default (if I'm understanding his earlier review
> comments to me).
Ok, I'll rebase onto FREELIST_HARDENED and test it all together.
> The second issue is what to DO when a double-free is
> discovered. Is there any way to make it safe/survivable? If not, I
> think it should just be BUG_ON(). If it can be made safe, then likely
> a WARN_ONCE and do whatever is needed to prevent the double-free.
Please correct me if I'm wrong. It seems to me that double-free is a dangerous
situation that indicates some serious kernel bug (which might be maliciously
exploited). So I would not trust / rely on the process which experiences a
double-free error in the kernel mode.
But I guess the reaction to it should depend on the Linux kernel policy of
handling faults. Is it defined explicitly?
Anyway, if we try to mitigate the effect from a double-free error _here_ (for
example, skip putting the duplicated object to the freelist), I think we should
do the same for other cases of double-free and memory corruptions.
>> If you insist on putting this check under CONFIG_FREELIST_HARDENED, should I
>> rebase onto your patch and send again?
> That would be preferred for me -- I'd like to have both checks. :)
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to email@example.com. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"firstname.lastname@example.org"> email@example.com </a>
next prev parent reply other threads:[~2017-07-19 8:39 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-17 16:45 [PATCH 1/1] mm/slub.c: add a naive detection of double free or corruption Alexander Popov
2017-07-17 16:57 ` Christopher Lameter
2017-07-17 17:54 ` Matthew Wilcox
2017-07-17 18:04 ` Christopher Lameter
2017-07-17 19:01 ` Alexander Popov
2017-07-17 19:11 ` Kees Cook
2017-07-18 19:56 ` Alexander Popov
2017-07-18 20:04 ` Kees Cook
2017-07-19 8:38 ` Alexander Popov [this message]
2017-07-19 14:02 ` Christopher Lameter
2017-07-18 14:57 ` Christopher Lameter
2017-07-17 18:23 ` Alexander Popov
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).