Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933661AbbLVUFD (ORCPT ); Tue, 22 Dec 2015 15:05:03 -0500 Received: from mail-pa0-f42.google.com ([209.85.220.42]:33606 "EHLO mail-pa0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933159AbbLVUE7 (ORCPT ); Tue, 22 Dec 2015 15:04:59 -0500 Subject: Re: [RFC][PATCH 0/7] Sanitization of slabs based on grsecurity/PaX To: Christoph Lameter References: <1450755641-7856-1-git-send-email-laura@labbott.name> Cc: Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Kees Cook , kernel-hardening@lists.openwall.com From: Laura Abbott Message-ID: <5679ACE9.70701@labbott.name> Date: Tue, 22 Dec 2015 12:04:57 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3458 Lines: 73 On 12/22/15 8:08 AM, Christoph Lameter wrote: > On Mon, 21 Dec 2015, Laura Abbott wrote: > >> The biggest change from PAX_MEMORY_SANTIIZE is that this feature sanitizes >> the SL[AOU]B allocators only. My plan is to work on the buddy allocator >> santization after this series gets picked up. A side effect of this is >> that allocations which go directly to the buddy allocator (i.e. large >> allocations) aren't sanitized. I'd like feedback about whether it's worth >> it to add sanitization on that path directly or just use the page >> allocator sanitization when that comes in. > > I am not sure what the point of this patchset is. We have a similar effect > to sanitization already in the allocators through two mechanisms: > > 1. Slab poisoning > 2. Allocation with GFP_ZERO > > I do not think we need a third one. You could accomplish your goals much > easier without this code churn by either > > 1. Improve the existing poisoning mechanism. Ensure that there are no > gaps. Security sensitive kernel slab caches can then be created with > the POISONING flag set. Maybe add a Kconfig flag that enables > POISONING for each cache? What was the issue when you tried using > posining for sanitization? The existing poisoning does work for sanitization but it's still a debug feature. It seemed more appropriate to keep debug features and non-debug features separate hence the separate option and configuration. > > 2. Add a mechanism that ensures that GFP_ZERO is set for each allocation. > That way every object you retrieve is zeroed and thus you have implied > sanitization. This also can be done in a rather simple way by changing > the GFP_KERNEL etc constants to include __GFP_ZERO depending on a > Kconfig option. Or add some runtime setting of the gfp flags somewhere. > That's good for allocation but sanitization is done on free. The goal is to reduce any leftover data that might be around while on an unallocated slab. > Generally I would favor option #2 if you must have sanitization because > that is the only option to really give you a deterministic content of > object on each allocation. Any half way measures would not work I think. > > Note also that most allocations are already either allocations that zero > the content or they are immediately initializing the content of the > allocated object. After all the object is not really usable if the > content is random. You may be able to avoid this whole endeavor by > auditing the kernel for locations where the object is not initialized > after allocation. > > Once one recognizes the above it seems that sanitization is pretty > useless. Its just another pass of writing zeroes before the allocator or > uer of the allocated object sets up deterministic content of the object or > -- in most cases -- zeroes it again. > The sanitization is going towards kernel hardening which is designed to help keep the kernel secure even when programmers screwed up. Auditing still won't catch everything. sanitization is going towards the idea of kernel self-protection which is what Grsecurity is known for and Kees Cook is trying to promote for mainline (http://lwn.net/Articles/662219/) Thanks, Laura -- 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/