Messages in this thread | | | Subject | Re: [kernel-hardening] Re: [RFC][PATCH 0/7] Sanitization of slabs based on grsecurity/PaX | From | Daniel Micay <> | Date | Tue, 22 Dec 2015 11:38:37 -0500 |
| |
> 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.[unhandled content-type:application/pgp-signature] | |