From mboxrd@z Thu Jan 1 00:00:00 1970 Reply-To: kernel-hardening@lists.openwall.com References: <1450755641-7856-1-git-send-email-laura@labbott.name> <5679ACE9.70701@labbott.name> From: Laura Abbott Message-ID: <568C8741.4040709@labbott.name> Date: Tue, 5 Jan 2016 19:17:21 -0800 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [kernel-hardening] Re: [RFC][PATCH 0/7] Sanitization of slabs based on grsecurity/PaX To: Kees Cook Cc: Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , Linux-MM , LKML , "kernel-hardening@lists.openwall.com" List-ID: 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