Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <86577436-c951-b687-f6fe-569693ef8c57@oracle.com>
Date: Fri, 17 Sep 2021 17:41:01 -0700
From: Alan Coopersmith <alan.coopersmith@...cle.com>
To: Keith Packard <keithp@...thp.com>, libc-coord@...ts.openwall.com
Subject: Re: freezero() and freezeroall()

On 9/17/21 5:09 PM, Keith Packard wrote:
> Alan Coopersmith <alan.coopersmith@...cle.com> writes:
> Given C compilers knowledge of 'free' semantics, I'm concerned that
> these fallbacks aren't actually doing what they think they're doing...

Some are better than others of course:
https://github.com/openssh/openssh-portable/blob/master/openbsd-compat/freezero.c

> With that in mind, adding this to the C library seems critical to me;
> that way, the application doesn't have to try to work around the
> compiler.

That was part of my motivation, though we already have explicit_bzero()
and explicit_memset() in our libc to help applications.

>> I'm working on adding it to the Solaris libc now, and since we can determine
>> the underlying allocation size, proposed also adding:
>>
>>                   void freezeroall(void *ptr);
>>
>> as basically doing: freezero(ptr, malloc_usable_size(ptr));
> 
> I'd suggest that your freezeroall call should be the only public
> function; we don't require that applications pass back the current size
> when calling realloc, after all. A fallback implementation could use
> malloc_usable_size, after all.

Except that malloc_usable_size() isn't quite universal yet - I know it's
in GNU libc, musl, FreeBSD libc, and Solaris libc, but I don't know about
others.  I see the OpenBSD 6.5 changelogs show they actually dropped it.
Mac OS X libc seems to spell it as "malloc_size()" instead.

The other benefit to having a size argument is performance - for instance,
password input functions today commonly accept strings up to 256 characters
or more, but the average user types a password less than 10% that size - so
why spend time clearing the other 90% of the buffer that's empty?  (It's not
a strong argument in many cases, since the performance difference of writing
an extra 230 bytes of zeros on modern processors is not noticeable by humans.)

-- 
	-Alan Coopersmith-               alan.coopersmith@...cle.com
	 Oracle Solaris Engineering - https://blogs.oracle.com/alanc

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.