Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754448AbbLVShm (ORCPT ); Tue, 22 Dec 2015 13:37:42 -0500 Received: from mail-yk0-f174.google.com ([209.85.160.174]:34140 "EHLO mail-yk0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752599AbbLVShl (ORCPT ); Tue, 22 Dec 2015 13:37:41 -0500 MIME-Version: 1.0 In-Reply-To: <56798D8F.9090402@labbott.name> References: <1450755641-7856-1-git-send-email-laura@labbott.name> <1450755641-7856-7-git-send-email-laura@labbott.name> <56798D8F.9090402@labbott.name> Date: Tue, 22 Dec 2015 19:37:40 +0100 Message-ID: Subject: Re: [kernel-hardening] [RFC][PATCH 6/7] mm: Add Kconfig option for slab sanitization From: Mathias Krause To: Laura Abbott 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 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1876 Lines: 45 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. >> 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. Regards, Mathias -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/