From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-f182.google.com (mail-pf0-f182.google.com [209.85.192.182]) by kanga.kvack.org (Postfix) with ESMTP id 7C0C682F64 for ; Tue, 22 Dec 2015 14:18:37 -0500 (EST) Received: by mail-pf0-f182.google.com with SMTP id q63so4616586pfb.0 for ; Tue, 22 Dec 2015 11:18:37 -0800 (PST) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com. [2607:f8b0:400e:c03::234]) by mx.google.com with ESMTPS id fi15si6211842pac.191.2015.12.22.11.18.36 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 22 Dec 2015 11:18:36 -0800 (PST) Received: by mail-pa0-x234.google.com with SMTP id jx14so93681311pad.2 for ; Tue, 22 Dec 2015 11:18:36 -0800 (PST) Subject: Re: [kernel-hardening] [RFC][PATCH 6/7] mm: Add Kconfig option for slab sanitization References: <1450755641-7856-1-git-send-email-laura@labbott.name> <1450755641-7856-7-git-send-email-laura@labbott.name> <56798D8F.9090402@labbott.name> From: Laura Abbott Message-ID: <5679A20A.6060407@labbott.name> Date: Tue, 22 Dec 2015 11:18:34 -0800 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Mathias Krause Cc: kernel-hardening@lists.openwall.com, Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , linux-mm@kvack.org, "linux-kernel@vger.kernel.org" , Kees Cook On 12/22/15 10:37 AM, Mathias Krause wrote: > On 22 December 2015 at 18:51, Laura Abbott wrote: >>> [snip] >>> >>> Related to this, have you checked that the sanitization doesn't >>> interfere with the various slab handling schemes, namely RCU related >>> specialties? Not all caches are marked SLAB_DESTROY_BY_RCU, some use >>> call_rcu() instead, implicitly relying on the semantics RCU'ed slabs >>> permit, namely allowing a "use-after-free" access to be legitimate >>> within the RCU grace period. Scrubbing the object during that period >>> would break that assumption. >> >> >> I haven't looked into that. I was working off the assumption that >> if the regular SLAB debug poisoning worked so would the sanitization. >> The regular debug poisoning only checks for SLAB_DESTROY_BY_RCU so >> how does that work then? > > Maybe it doesn't? ;) > > How many systems, do you think, are running with enabled DEBUG_SLAB / > SLUB_DEBUG in production? Not so many, I'd guess. And the ones running > into issues probably just disable DEBUG_SLAB / SLUB_DEBUG. > > Btw, SLUB not only looks for SLAB_DESTROY_BY_RCU but also excludes > "call_rcu slabs" via other mechanisms. As SLUB is the default SLAB > allocator for quite some time now, even with enabled SLUB_DEBUG one > wouldn't be able to trigger RCU related sanitization issues. > I've seen SLUB_DEBUG used in stress testing situations but you're right about production and giving up if there are issues. I'll take a closer look at this. >>> Speaking of RCU, do you have a plan to support RCU'ed slabs as well? >>> >> >> My only plan was to get the base support in. I didn't have a plan to >> support RCU slabs but that's certainly something to be done in the >> future. > > "Base support", in my opinion, includes covering the buddy allocator > as well. Otherwise this feature is incomplete. Point taken. I'll look at the buddy allocator post-holidays. It was also pointed out I should be giving you full credit for this feature originally. I apologize for not doing that. Thanks for doing the original work and taking the time to review this series. Thanks, Laura -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org