public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Paul Eggert <eggert@cs.ucla.edu>
To: Florian Weimer <fweimer@redhat.com>,
	GNU C Library <libc-alpha@sourceware.org>
Subject: Re: [PATCH] malloc: Implement heap protector
Date: Fri, 28 Oct 2016 17:56:00 -0000	[thread overview]
Message-ID: <7b7d32d4-b66c-4b87-9509-a9ed4df62b85@cs.ucla.edu> (raw)
In-Reply-To: <dd818b8d-7176-8490-0780-e6e25756323a@redhat.com>

Thanks for working on this. The idea looks good. I second Carlos's 
comments on comment and NEWS. Some other (minor) issues:

 > +/* The heap cookie.  The lowest three bits (corresponding to
 > +   SIZE_BITS) in __malloc_guard_header must be clear. Initialized

It's __malloc_header_guard, not __malloc_guard_header.

 > +   during libc startup, and computed by elf/dl-keysetup.c.  */
 > +INTERNAL_SIZE_T __malloc_header_guard; /* For size.  */
 > +INTERNAL_SIZE_T __malloc_footer_guard; /* For prev_size.  */

Why two cookies? Doesn't one suffice, and mightn't that be a tad more 
efficient? The comment should explain.

 > +/* Decrypt a heap header chunk.  */

These macros both encrypt and decrypt, right?  At least, they're used 
that way.  The comment should say so.

Come to think of it, suppose we want to microimprove the implementation 
to use val+guard to encrypt and val-guard to decrypt; this might be bit 
faster on some platforms, and would be safe in unsigned arithmetic. 
Would we then need two sets of macros, one for encryption and one for 
decryption?  Then perhaps we should have two sets of macros now, even 
though the implementations are the same now, to make invoking code 
clearer and more-portable to a +/- approach.

 > +#define HEAP_CRYPT_SIZE(val) (__malloc_header_guard ^ 
((INTERNAL_SIZE_T) val))
 > +#define HEAP_CRYPT_PREVSIZE(val) \
 > +  (__malloc_footer_guard ^ ((INTERNAL_SIZE_T) val))

'val' needs to be parenthesized in these two macro definientia.

 > +#define set_foot(p, s) \
 > +  (((mchunkptr) ((char *) (p) + (s)))->mchunk_prev_size \
 > +    = HEAP_CRYPT_PREVSIZE (s))

Last line is indented one space too much.

 > +      else if (usable > size + 4096)

Rephrase as 'usable - size > 4096' so that we don't have to worry about 
SIZE being ridiculously large.  The subtraction cannot possibly overflow 
here.

 > +     are treated as fake mmapped chunks.  We cannot use the regular
 > +     accessors because the chunks we read are not yet encrypted.  */

Avoid the royal "we", and use imperative voice instead: "We cannot use" 
-> "Don't use", "the chunks we read" -> "the chunks read".

 > +      /* We treat all chunks as allocated.
...
 > +  /* In the non-shared case, we initialize the heap guard
 > +     directly.  */
...
 > +  /* For a shared library, elf/rtld.c performed key setup in
 > +     security_init, and we copy the keys.  In static builds, the guard
...
 > +/* After heap initialization, we can call malloc_usable_size to check
 > +   if it gives valid results.  */
...
 > +  /* The heap has been initialized.  We may now call
 > +     malloc_usable_size.  */

Similarly, avoid "we".

  parent reply	other threads:[~2016-10-28 17:56 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-28 13:17 Florian Weimer
2016-10-28 15:05 ` Carlos O'Donell
2016-10-28 17:56 ` Paul Eggert [this message]
2016-11-08 15:13   ` Florian Weimer
2016-11-08 16:09     ` Andreas Schwab
2016-11-10 15:39     ` Florian Weimer
2016-10-28 20:45 ` DJ Delorie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7b7d32d4-b66c-4b87-9509-a9ed4df62b85@cs.ucla.edu \
    --to=eggert@cs.ucla.edu \
    --cc=fweimer@redhat.com \
    --cc=libc-alpha@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).