From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752203AbcAFDR0 (ORCPT ); Tue, 5 Jan 2016 22:17:26 -0500 Received: from mail-pa0-f42.google.com ([209.85.220.42]:33270 "EHLO mail-pa0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751809AbcAFDRY (ORCPT ); Tue, 5 Jan 2016 22:17:24 -0500 Subject: Re: [RFC][PATCH 0/7] Sanitization of slabs based on grsecurity/PaX To: Kees Cook References: <1450755641-7856-1-git-send-email-laura@labbott.name> <5679ACE9.70701@labbott.name> Cc: Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , Linux-MM , LKML , "kernel-hardening@lists.openwall.com" From: Laura Abbott Message-ID: <568C8741.4040709@labbott.name> Date: Tue, 5 Jan 2016 19:17:21 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 1/5/16 4:09 PM, Kees Cook wrote: > On Tue, Dec 22, 2015 at 12:04 PM, Laura Abbott wrote: >> 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. > > This looks great! I love the added lkdtm tests, too. Very cool. > >>> 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. > > What stuff is intertwined in the existing poisoning that makes it > incompatible/orthogonal? > It's not the poisoning per se that's incompatible, it's how the poisoning is set up. At least for slub, the current poisoning is part of SLUB_DEBUG which enables other consistency checks on the allocator. Trying to pull out just the poisoning for use when SLUB_DEBUG isn't on would result in roughly what would be here anyway. I looked at trying to reuse some of the existing poisoning and came to the conclusion it was less intrusive to the allocator to keep it separate. Thanks, Laura