[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 22 Dec 2015 11:38:37 -0500
From: Daniel Micay <danielmicay@...il.com>
To: kernel-hardening@...ts.openwall.com, Laura Abbott <laura@...bott.name>
Cc: Pekka Enberg <penberg@...nel.org>, David Rientjes <rientjes@...gle.com>,
Joonsoo Kim <iamjoonsoo.kim@....com>, Andrew Morton
<akpm@...ux-foundation.org>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org, Kees Cook <keescook@...omium.org>
Subject: Re: Re: [RFC][PATCH 0/7] Sanitization of slabs
based on grsecurity/PaX
> 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:
The rationale was covered earlier. Are you responding to that or did you
not see it?
> 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?
>
> 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.
>
> 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.
Sanitization isn't just to prevent leaks from usage of uninitialized
data in later allocations. It's a mitigation for use-after-free (esp. if
it's combined with some form of delayed freeing) and it reduces the
lifetime of data.
Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
