[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YUVANGjmunycihY0@gmail.com>
Date: Fri, 17 Sep 2021 21:26:12 -0400
From: Bryan Steele <brynet@...il.com>
To: libc-coord@...ts.openwall.com
Subject: Re: freezero() and freezeroall()
On Fri, Sep 17, 2021 at 05:46:26PM -0700, Paul Eggert wrote:
> On 9/17/21 4:36 PM, Konstantin Belousov wrote:
> > And what does the function do if the page is co-populated by unrelated
> > allocations?
>
> explicit_bzero is supposed to be used in that case, according to the OpenBSD
> doc. (But see below.)
>
> > BTW is clearing done by userspace or kernel? Does kernel ensure that
> > possible copies anywhere, e.g. in swap, are obliterated as well?
>
> When explicit_bzero is not used, munmap is supposed to be used. I don't know
> whether munmap obliterates swap.
>
> 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.
>
> OpenBSD freezero is tightly linked to reallocarray, in that reallocarray is
> documented to clear any old object with explicit_bzero before returning the
> new object's address. If this is the idea, it makes little sense to add
> freezero without also modifying reallocarray. Unfortunately, a reasonable
> amount of GNU code is written assuming that reallocarray is not
> significantly slower than realloc so this approach sounds dubious.
You misread. reallocarray and re*calloc*array are different functions.
> 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.)
>
> One minor QoI detail: OpenBSD freezero is slower than 'free' for other
> reasons, as it does more checking of internal data structures. I guess the
> idea is that freezero is gonna be slow anyway, so why not?
>
> [1] https://github.com/openbsd/src/blob/master/lib/libc/stdlib/malloc.c
>
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.
