> 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.
Attachment:
signature.asc
Description: This is a digitally signed message part