Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 4 Oct 2021 18:22:39 -0700
From: Alan Coopersmith <>
To: Paul Eggert <>,
        Konstantin Belousov <>
Cc:, Keith Packard <>
Subject: Re: freezero() and freezeroall()

On 9/17/21 5:46 PM, Paul Eggert wrote:
> Looking at the current OpenBSD source code[1], it appears they're doing best 
> effort. Unless I'm missing something, in some cases freezero appears to call 
> memset instead of explicit_bzero. Even if that were changed, on real systems I 
> expect the data are too often still lying around somewhere in the hardware. I 
> suppose the idea is that it's better than nothing.

I believe the goal is to protect against the memory being visible in core files
and to debuggers, not to a physical RAM dump of some sort.

> With all this in mind it would be better to add a better API, as Alan proposed, 
> than to standardize on freezero. The name 'freezeroall' is a bit hard to read, 
> though - how about calling it 'clearfree' instead? ("clear" before "free" 
> because that's the order it's conceptually done.)

I picked freezeroall() to follow on from the existing and already spreading
freezero(), but if there's a different name that other libc implementations
would like to standardize on and adopt, I'm open to using that instead.

While cfree() to mirror calloc() is tempting, history already claimed that
name and it's best not to re-use:

C23 seems to be using the convention that alternatives to free() still
start with the "free_" prefix:
(as discussed on this list back in February in the thread
  "Sized deallocation for C" archived on )

	-Alan Coopersmith-     
	 Oracle Solaris Engineering -

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.