From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 63094 invoked by alias); 28 Oct 2016 20:45:58 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 63068 invoked by uid 89); 28 Oct 2016 20:45:58 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.3 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mx1.redhat.com From: DJ Delorie To: Florian Weimer Cc: GNU C Library Subject: Re: [PATCH] malloc: Implement heap protector References: Date: Fri, 28 Oct 2016 20:45:00 -0000 In-Reply-To: (Florian Weimer's message of "Fri, 28 Oct 2016 15:17:22 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2016-10/txt/msg00574.txt.bz2 My only comments on this one are: > +/* Decrypt a heap header chunk. */ > +#define HEAP_CRYPT_SIZE(val) (__malloc_header_guard ^ ((INTERNAL_SIZE_T) val)) > +#define HEAP_CRYPT_PREVSIZE(val) \ > + (__malloc_footer_guard ^ ((INTERNAL_SIZE_T) val)) For readability and maintainability, we should probably have both CRYPT and DECRYPT macros, used correcly throughout. Yes, I know they'd be the same now, but they might not be later. > +/* The heap cookie. The lowest three bits (corresponding to > + SIZE_BITS) in __malloc_guard_header must be clear. Initialized > + during libc startup, and computed by elf/dl-keysetup.c. */ If the lowest three bits must be clear, we should either clear them or assert that they're clear.